RE: [vhdl-200x] VHDL enhancements wish list

YEAH!!!
This may be the first time I had heard someone acknowledge that VHDL is a
programming language.
Somebody other than me!! I have been stating in my HDL class since the
early 1990s that VHDL is
A decent concurrent programming language, although the overhead for
execution (as it an HDL), if using it for
Creating concurrent programs, is too high for such use.

VHDL was designed to model digital hardware. Digital hardware is concurrent
and by nature a language
To represent it needs to be concurrent. Digital hardware is (for the most
part) deterministic and
A language for it should also be deterministic. VHDL's paradigm is
deterministic.

Joanne

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
ryan.w.hinton@L-3com.com
Sent: Friday, February 18, 2011 3:25 PM
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] VHDL enhancements wish list

Replies inline below.

-----Original Message-----
From: Jim Lewis [mailto:Jim@SynthWorks.com]
Sent: Thursday, February 17, 2011 12:28 PM
To: Hinton, Ryan W @ CSG - CSW
Subject: Re: VHDL enhancements wish list

> Ryan,
> Probably want to post this to the reflector.
>
> I put my comments in below.
>
> Best,
> Jim
>
> > 1. Shorthand for clocked process. It seems silly for an HDL to
> > require coding conventions to describe 90+% of designs, namely
> > clocked processes. Instead, (or in addition for the foreseeable
> > future) VHDL could support something like the following.
> >
> > label: process clock(Clk) is
> > -- declaration region for constants, variables, aliases, etc.
> > synchronous reset(Rst)
> > -- reset logic
> > begin
> > -- non-reset logic
> > end process;
>
> -- Are these ok?
> AReg <= A when rising_edge(Clk) ;
> AReg <= mux(nReset, "0000", A) when rising_edge(Clk) ; AReg <= "0000"
> when not nReset else A when rising_edge(Clk) ;

Very nice! Now I know a few more ways to infer synchronous logic. If I
understand correctly, the first is a FF, the second is a FF with
synchronous reset, and the third is a FF with asynchronous reset.

These are great for single signals, but I'm thinking of a whole
component. I wouldn't want to have to add "when rising_edge(Clk)" to
every statement.

> I have also been thinking we need a standard set of RTL
> procedures/functions that work as low level components:
>
> AsyncReg(Clk, nReset, "0000", A, AReg) ;
>
> Y <= Mux2(Sel, A, C) + Mux2(Sel, B, D) ;
>
> It sure would be nice to be able to reuse IP even when the polarity of

> Clk and Reset change or if we need to change between asynchronous and
> synchronous resets. A package based implementation that changes the
> package body could easily do this. Maybe named package bodies and a
> method of selecting them would be nice.

I like this idea. It's similar to a recent idea of mine. I think we
need an equivalent of Boost for VHDL. Boost is an set of libraries for
C++ that supplements the built-in, standardized C++ library. I was
pleased nearly to tears when I discovered that it solved several
problems I've been struggling with in some applications of mine. I'm
always happy to steal someone else's already-tested code instead of
write and debug my own.

I think we should do this for VHDL. We could start with the matrix
package that has been proposed. I want to add some unconstrained
element array types with signed/unsigned/sfixed/ufixed element types.
(I don't use the floating-point types, but someone who does should
probably do the same for them, too.) Then I want a package that defines
a COMPLEX type as a two-element array of unconstrained sfixed and all
the arithmetic and resizing functions for this type. (Maybe COMPLEX
should be defined for REAL and define CFIXED for the SFIXED element type
instead.)

Besides math packages, we can do the same for text and general-purpose
programming utilities. Granted it's a stretch, but what's preventing us
from having a regular expressions library for VHDL strings? Why can't
we have smart pointers or abstract data types? We could probably port
much of the C++ standard library (and Boost) already, and we could
probably handle the rest if we add object-oriented features to the
language. I think we should look at more recent languages like Python
and Ruby as well to see if we can borrow any good ideas.

People tend to forget that VHDL was originally a hardware description
language. As such, it's a full-featured programming language. Yes, I
want special stuff like "process clock(Clk)" because it is a *hardware*
language. But I don't see any reason that I can't have all the richness
and power of a general-purpose language. Sockets library, anyone? :-)

I'm aware that this general-purpose language approach contradicts my
earlier stand about VHDL being a hardware language. I guess I want
both. When I'm describing hardware, I want it to be clear and concise.
When I'm testing my hardware I find myself doing lots of file and text
processing, so I want a good general-purpose programming language. I
really like the idea of making VHDL easy to integrate with C and other
languages (my current favorite is Ruby), but it's always simpler to stay
in VHDL when possible. My point is that *much more* is possible, it
just hasn't been written yet.

> > 2. Shorthand for pipelining. This is another common operation that

> > could be easier -- but it has significant side-benefits as well.
> > Typically, pipelining a signal or an operation requires defining
> > additional signals and/or variables to hold intermediate values,
> > shifting values in and out, etc. Instead, VHDL could support
> > something like the following inside a clocked process (perhaps
> > limited to the syntax above).
> >
> > Product<= A * B after 2 cycles;
> >
> > We could specify "clocks" instead of "cycles" if preferred, or
> > possibly allow either.
>
> Would a subprogram be ok:
> PipeReg(Clk, A*B, Result, 2) ; -- where 2 is the number of stages.

A subprogram would get rid of the annoyance, but it doesn't offer the
synthesis and formal verification advantages. It's also not as clear
and concise. Your approach has the advantage of being *possible* right
now. But we're discussing things that are currently impossible. :-)

Incidentally, if the procedure call is inside a clocked process, you
don't need the clock input.

> Implementation takes something that is not synthesizable right now:
> procedure PipeReg (
> signal Clk : std_logic ;
> ValIn : anonymous ; -- one of my requests
> signal Valout : out ValIn'subtype ;
> Stages : integer := 2
> ) is
> type PipeRegType is array (1 to Stages) of ValIn'subtype ;
> variable PipeReg : PipeRegType ;
> begin
> loop
> wait until Clk = '1' ;
> PipeReg := PipeReg(2 to Stages) & ValIn ;
> ValOut <= PipeReg(1) ;
> end loop ;
> end procedure PipeReg ;
>
> If you want it to synthesize now, you will need to pass in PipeRegType

> would would require something like:
> procedure PipeReg (
> signal Clk : std_logic ;
> ValIn : anonymous ; -- one of my requests
> signal Valout : out ValIn'subtype ;
> Stages : integer range 2 to integer'high ;
> signal PipeReg : array(1 to Stages-1) of ValIn'subtype
> ) is
> begin
> loop
> wait until Clk = '1' ;
> PipeReg <= PipeReg(2 to Stages-1) & ValIn ;
> ValOut <= PipeReg(1) ;
> end loop ;
> end procedure PipeReg ;
>
>
> Of course, if I am going to specify PipeReg externally to the
> subprogram, why not just write:
>
> PipeReg <= PipeReg(2 to (PipeReg'right-1)) & A*B when rising_edge(Clk)

> ;
>
> Or you could just do the shifting in interface of a subprogram call:
> Reg(Clk, PipeReg(2 to STAGES) & (A*B), PipeReg(1 to STAGES)) ;

Again, all of these are good suggestions of valid (or mostly valid)
approaches to specify pipelining now. But I still prefer my syntax. I
pipeline signals in nearly every module I write, so it would be a
frequently-appreciated improvement for me.

> > 3. Object-oriented language features. For a discussion of syntax
> > and benefits see e.g.
> >
> > http://www.ashenden.com.au/suave.html
>
> There is also some old stuff on eda.org that I need to look to see if
> it is still accessible.
>
> I see OO as a foundation feature on top of which we can build
> verification data structures (such as scoreboards - which I already
> have in protected types), randomization (since it is really a process
> of managing a database of constraints), and functional coverage (not
> sure I need OO, but I need some type of call back/function pointer to
> do centralized reporting of coverage).

Exactly. I included (3) on my list because I don't remember seeing it
recently. I included (4) to give my 2 cents on whether to address
verification features. (I think we should.)

Enjoy!

---
Ryan Hinton
L-3 Communications / Communications Systems-West
ryan.w.hinton@L-3com.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.