VHDL Feature Suggestions

J

Jonathan Ross

Guest
I have only been programming full-time in VHDL for a little over a
year so I tend to be skeptical at my ability to come up with
suggestions that would enhance the language. So before I go through
any process to make any official request I'd like to get some feedback
here on a few ideas that I've felt would improve the VHDL experience.

1. 'SCOPE' or 'CONTEXT' - a keyword to define a scope. An example
usage follows:

CountDown : CONTEXT
VARIABLE Counter : UNSIGNED( 15 DOWNTO 0 ) :=
x"FFFF";
BEGIN
Counter := Counter - 1;
END CONTEXT CountDown;

Counter := Counter - 1; -- Error: Counter is not
defined here.

This is a trivial example, but the idea is as follows. Many variables
are used only a few times and in a small section. By having the
variable declaration close to where it's used it makes the code more
readable as the programmer does not need to search through the file
for the definition. Originally the idea was to simply allow the BEGIN
keyword to be used in IF statements, but the syntax would be very odd
with respect to how it would look if you used ELSE statements. This is
broader. I would suggest CONTEXT be allowed both within a process body
and outside of it for the benefit of concurrent statements. This
models one of the uses of the curly brackets in C++.

2. Often times signals are used only within a single process because
the semantics are ideal if you don't want changes to take effect until
the next clock cycle. For example, all of my state machines, even if
they're only defined within a process, are signals. Similar to the
above reasoning of keeping variable declarations close to where
they're used, I'd like to see the SIGNAL keyword be legal to use
wherever you can use VARIABLE. I realize simulators require more CPU
resources to simulate signals than variables and so some people try to
discourage their use, but for those of us who use them often I feel
this would help readability.

3. This is less well thought out than the two above and comes more in
the shape of a problem than a solution. VHDL's ability for static
elaboration is amazing in comparison to many other languages (i.e. C+
+). However, consider the following type. Imagine that I wanted to
implement a LFSR that cycles every N increments. Can this be coded in
VHDL 2008? I.E., can I have something like the following:

TYPE lfsr5 IS lfsr( period => 5 );
....
VARIABLE state : lfsr5 := lfsr5'POS(0);
....

CASE state IS
WHEN lfsr5'POS(0) => ...
WHEN lfsr5'POS(1) => ...
...
WHEN lfsr5'POS(4) => ...
END CASE;

state := state + 1;

I don't see how to do anything quite like that at the moment. The
values of POS(0) through POS(1) for an LFSR depend on the period so
they would need to be generated during elaboration. I wouldn't mind a
custom attribute other than POS to be used, I just don't see how to do
this as a generic variable. If I'm mistaken please let me know.
 
It seems like what you want for #1 is to be able to use the block
statement as a sequential statement. It would be just as valuable, and
syntactically simpler, to allow declarative regions within control
statements (if, case, loop, etc.; anything with an "end" should be
able to have a declarative region).

An existing solution to #2 is to wrap your process with a block
statement that declares the signals that are "local" to the process.
This can also be used to declare signals (and types) that are used to
communicate only between two processes (e.g. a clocked and combo
process pair) by putting both processes in the same block.

Opinions vary, but the semantics of signal assignment/update rarely
lead to a "more readable" description within a process. I prefer the
semantics of variables because it "reads" like it executes. There is
no hidden "oh, this doesn't actually change until the process
suspends" garbage.

I have no comment on #3.

Andy
 
On Nov 11, 1:17 pm, Andy <jonesa...@comcast.net> wrote:
It seems like what you want for #1 is to be able to use the block
statement as a sequential statement. It would be just as valuable, and
syntactically simpler, to allow declarative regions within control
statements (if, case, loop, etc.; anything with an "end" should be
able to have a declarative region).

An existing solution to #2 is to wrap your process with a block
statement that declares the signals that are "local" to the process.
This can also be used to declare signals (and types) that are used to
communicate only between two processes (e.g. a clocked and combo
process pair) by putting both processes in the same block.

Opinions vary, but the semantics of signal assignment/update rarely
lead to a "more readable" description within a process. I prefer the
semantics of variables because it "reads" like it executes. There is
no hidden "oh, this doesn't actually change until the process
suspends" garbage.

I have no comment on #3.

Andy
Click to expand...
Thanks - very informative. Yes, I suppose I am simply looking for a
sequential version of block. As I said, my original suggestion was
going to be to allow the use of BEGIN within control statements, but
the following usage bothered me:

IF Condition THEN
VARIABLE LocalValue : LocalType := LocalInitialization;
BEGIN
DoSomething;
ELSE
DoSomethingElse;
END IF;

Is LocalValue defined in both branches of the if statement? We'd want
it to be so, yes, but I could see how it might possibly lead to
occasional (and/or newbie) confusion.

The other issue was that if the BEGIN syntax is used as above it would
lead to the BEGIN keyword being optional in some locations and
mandatory in others (unless the definitions of many other keywords).
Although I will admit that there are many times I've wanted to not
write BEGIN (i.e. functions/procedures/processes where I have no
variables...), there does tend to be inertia to such wide-scale
changes, even if they don't break previous code.

As for the comment on #2, this certainly does most of what I want, and
a bit more. That said, when I use a signal purely inside a process
it's not as clean, but it'll certainly help make my code at least a
little more readable, especially in the clocked/combo pair example you
cited.

Often times I find myself write code "backwards" though when I use
variables instead of signals. I.E., if I have the following schedule
of tasks to accomplish, each taking 1 clock cycle, and depending on
each other: A < B < C, that is C depends on the result of B depends on
the result of A, if their results are output as variables I tend to
write the code:

C
B
A

This is (to me) more opaque to read. But different developers will do
things differently, and as long as people are using signals the way I
use them, it would be nice to be able to declare them closer to where
they're used.
 
On Nov 11, 1:53 pm, Jonathan Ross <TheProperN...@psychophile.com>
wrote:
Thanks - very informative. Yes, I suppose I am simply looking for a
sequential version of block. As I said, my original suggestion was
going to be to allow the use of BEGIN within control statements, but
the following usage bothered me:

IF Condition THEN
   VARIABLE LocalValue : LocalType := LocalInitialization;
BEGIN
   DoSomething;
ELSE
   DoSomethingElse;
END IF;

Is LocalValue defined in both branches of the if statement? We'd want
it to be so, yes, but I could see how it might possibly lead to
occasional (and/or newbie) confusion.
Click to expand...
Every other place BEGIN is used in VHDL, its context continues until
the corresponding END.

I could easily agree with a change that made BEGIN keywords optional
if there were no declarative region needed, for all cases, including
process, architecture, etc. "IS" is already optional after PROCESS
(...).

Often times I find myself write code "backwards" though when I use
variables instead of signals. I.E., if I have the following schedule
of tasks to accomplish, each taking 1 clock cycle, and depending on
each other: A < B < C, that is C depends on the result of B depends on
the result of A, if their results are output as variables I tend to
write the code:

C
B
A

This is (to me) more opaque to read.
Click to expand...
That's part of the unintuitiveness of signals:

a <= b;
b <= c;

has exactly the same results as:

b <= c;
a <= b;

This is not intuitive.

The difference in behavior between sequential signal assignments and
concurrent signal assignments is muddied because the order of
statements does not matter in either case, which leads to lots of
confusion with newbies. A sequential signal assignment is not quite
sequential, but not quite concurrent either.

With variables, the assignment executes entirely in the order it is
written, and as expected, the different orders have different results.

Having to "reverse the order" is no different whether you are writing
code for compilation and execution on a processor, or on an FPGA/ASIC.

Andy
 
On Nov 11, 6:50 pm, Andy <jonesa...@comcast.net> wrote:
On Nov 11, 1:53 pm, Jonathan Ross <TheProperN...@psychophile.com
wrote:





Thanks - very informative. Yes, I suppose I am simply looking for a
sequential version of block. As I said, my original suggestion was
going to be to allow the use of BEGIN within control statements, but
the following usage bothered me:

IF Condition THEN
   VARIABLE LocalValue : LocalType := LocalInitialization;
BEGIN
   DoSomething;
ELSE
   DoSomethingElse;
END IF;

Is LocalValue defined in both branches of the if statement? We'd want
it to be so, yes, but I could see how it might possibly lead to
occasional (and/or newbie) confusion.

Every other place BEGIN is used in VHDL, its context continues until
the corresponding END.

I could easily agree with a change that made BEGIN keywords optional
if there were no declarative region needed, for all cases, including
process, architecture, etc.  "IS" is already optional after PROCESS
(...).

Often times I find myself write code "backwards" though when I use
variables instead of signals. I.E., if I have the following schedule
of tasks to accomplish, each taking 1 clock cycle, and depending on
each other: A < B < C, that is C depends on the result of B depends on
the result of A, if their results are output as variables I tend to
write the code:

C
B
A

This is (to me) more opaque to read.

That's part of the unintuitiveness of signals:

a <= b;
b <= c;

has exactly the same results as:

b <= c;
a <= b;

This is not intuitive.

The difference in behavior between sequential signal assignments and
concurrent signal assignments is muddied because the order of
statements does not matter in either case, which leads to lots of
confusion with newbies. A sequential signal assignment is not quite
sequential, but not quite concurrent either.

With variables, the assignment executes entirely in the order it is
written, and as expected, the different orders have different results.

Having to "reverse the order" is no different whether you are writing
code for compilation and execution on a processor, or on an FPGA/ASIC.
Click to expand...
When you say "unintuitive" you mean you have learned how software
works and had to relearn how hardware works. HDL is the way it is
because it is describing hardware. Trying to treat HDL like software
may result in a working design, but has great potential to cause
problems.

Yes, if you already know how procedural languages work, you will have
to forget that or at least not think HDL is similar. I know that is
what I had to do.

Rick
 
Andy <jonesandy@comcast.net> writes:

It seems like what you want for #1 is to be able to use the block
statement as a sequential statement. It would be just as valuable, and
syntactically simpler, to allow declarative regions within control
statements (if, case, loop, etc.; anything with an "end" should be
able to have a declarative region).
Click to expand...
Which is the C99 and C++ way (dunno if that's in its favour or not
:) Personally, I'd like it.

I think the "if blah then variable.... begin... else... end;" proposal
made downthread could work well.

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
 
Jonathan,
Now once you have written about what you want, if you would like to
make an official feature request to the VHDL working group, you can
submit an enhancement request at:
http://www.eda.org/vasg/

Look on the left hand side of the page for enhancement & bug request

Best,
Jim
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top