Why Doesn't VHDL Have a Wildcard Sensitivity List?

[rickman]

The title is self explanatory. When found that Verilog lets you use a
* in the sensitivity list of a combinatorial process. Why doesn't
VHDL have that? There doesn't seem to be a down side that I can think
of. Didn't they just finalize changes to VHDL in 2008? Isn't seven
years enough time to pick up on a useful feature like this?

Rick

 

[HT-Lab]

Someone correct me if I'm wrong, but I think VHDL2008 allows for 'all' as a
sensitivity list.

Yes process(all) works fine in Modelsim 10.0 and ActiveHDL/Riviera, not sure
about ncsim, isim etc.

Now, that said, just TRY to find a synthesis tool that supports it.

Precision and Synplify and I believe QNS (not 100% sure),

Hans
www.ht-lab.com

 

[Jonathan Bromley]

The title is self explanatory. When found that Verilog lets you use a
* in the sensitivity list of a combinatorial process. Why doesn't
VHDL have that? There doesn't seem to be a down side that I can think
of. Didn't they just finalize changes to VHDL in 2008? Isn't seven
years enough time to pick up on a useful feature like this?

heh. As others have said, "process(all)" is in
VHDL-2008 and it's just a matter of waiting for
Your Favourite Tool (TM) to support it.

However, don't believe everything you read in the
headlines. You do know about the flaws in
Verilog @*, don't you?

 

[Gabor Sz]

heh. As others have said, "process(all)" is in
VHDL-2008 and it's just a matter of waiting for
Your Favourite Tool (TM) to support it.

However, don't believe everything you read in the
headlines.  You do know about the flaws in
Verilog @*, don't you?

In my experience the "flaws" of Verilog @* don't show up under
typical design conditions. For example when implementing a
memory, I understand that the block won't fire in simulation
just because the currently addressed cell of memory changes,
however most of the time I'm using non-clocked memory I only
expect the value to change due to a change in the address,
i.e. I don't write the memory cell while reading the same
cell. For a large combinatorial process, the likelihood of
forgetting an item in the sensitivity list becomes more of
a "flaw" than the little quirks of @*. Obviously you can
look through the warnings and complete the list recursively,
assuming you synthesize the code before you're done debugging
it in behavioral simulation where leaving out an item is
not considered worthy of a warning.

Just my 2 cents,
Gabor

 

[Jonathan Bromley]

In my experience the "flaws" of Verilog @* don't show up under
typical design conditions. For example when implementing a
memory, I understand that the block won't fire in simulation
just because the currently addressed cell of memory changes,
however most of the time I'm using non-clocked memory I only
expect the value to change due to a change in the address,
i.e. I don't write the memory cell while reading the same
cell. For a large combinatorial process, the likelihood of
forgetting an item in the sensitivity list becomes more of
a "flaw" than the little quirks of @*. Obviously you can
look through the warnings and complete the list recursively,
assuming you synthesize the code before you're done debugging
it in behavioral simulation where leaving out an item is
not considered worthy of a warning.

Sure, there's no doubt @* is a big win.

always_comb (the pumped-up SystemVerilog version
of always@*) fixes the array sensitivity problem,
and also the issue about sensitivity to free
variables that are read by called functions.
That problem with @* is, I reckon, at least as
dangerous as array (in)sensitivity.

Good point about using your synthesis tool to
flush out any problems, though. And of course a
good linting or formal checking tool would tell
you the same things.

On a purely practical note, it's worth remembering
that continuous assign *is* sensitive to everything
it needs, including arrays. So it's probably a
better choice than always@* for modelling the
"read" side of an asynchronous memory.

cheers

 

[backhus]

Sure, there's no doubt @* is a big win.

always_comb (the pumped-up SystemVerilog version
of always@*) fixes the array sensitivity problem,
and also the issue about sensitivity to free
variables that are read by called functions.  
That problem with @* is, I reckon, at least as
dangerous as array (in)sensitivity.

Good point about using your synthesis tool to
flush out any problems, though.  And of course a
good linting or formal checking tool would tell
you the same things.

On a purely practical note, it's worth remembering
that continuous assign *is* sensitive to everything
it needs, including arrays.  So it's probably a
better choice than always@* for modelling the
"read" side of an asynchronous memory.

cheers

Hi everybody
if you want to implement the all keyword in your favorite synthesis
tool, you can do it like this:

signal all : std_logic ;

Now you can use

process(all)

in your non-VHDL2008 synthesis tool, and it won't throw errors. (Maybe
warnings, but these can be filtered out)

Maybe you can put this declaration in a global package that you use
for synthesis only, to avoid conflicts with a VHDL2008 compatible
simulator.

Have a nice synthesis
Eilert

 

[HT-Lab]

Yes process(all) works fine in Modelsim 10.0 and ActiveHDL/Riviera, not sure
about ncsim, isim etc.


Precision and Synplify and I believe QNS (not 100% sure),

QNS (Quartus 10.1) supports it as well, XST(ISE 12.3) does not.

Hans
www.ht-lab.com

 

[rickman]

Hi everybody
if you want to implement the all keyword in your favorite synthesis
tool, you can do it like this:

signal all : std_logic ;

Now you can use

process(all)

in your non-VHDL2008 synthesis tool, and it won't throw errors. (Maybe
warnings, but these can be filtered out)

Maybe you can put this declaration in a global package that you use
for synthesis only, to avoid conflicts with a VHDL2008 compatible
simulator.

You lost me somewhere. How will this work at all in simulation?

Rick

 

[Walter]

VHDL is a reasonably safe hardware description language; why we insist
on make holes over the bridge ?

Walter



--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---

 

[d_s_klein]

VHDL is a reasonably safe hardware description language; why we insist
on make holes over the bridge ?

Walter

--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---

I thought that I was the only one who thought that.

Why would one want to make it harder to spot mistakes?

I have spent many hours debugging code where shortcuts had allowed
"bad things" to go undetected. For my time and energy, it's less work
to do it the old way than to manually sift through the code.

RK

 

[rickman]

VHDL is a reasonably safe hardware description language; why we insist
on make holes over the bridge ?

Walter

--- news://freenews.netfront.net/ - complaints: (e-mail address removed) ---

How is the "all" keyword a hole? VHDL may be "safe", but so are four
point harnesses and full helmets. You don't see them used in standard
automobiles, instead we opt for a tradeoff between safety and
convenience. Forgetting a signal in the sensitivity list of a
combinatorial process (such as a complex case statement) is not an
uncommon mistake. I believe the tools will give you warnings about
this, but why bother with all that when you can just say "use all
input signals in the sensitivity list... stupid" to the tools? Where
is the danger?

Rick

 

[rickman]

I thought that I was the only one who thought that.

Why would one want to make it harder to spot mistakes?

I have spent many hours debugging code where shortcuts had allowed
"bad things" to go undetected.  For my time and energy, it's less work
to do it the old way than to manually sift through the code.

I'm not following. How would using the "all" keyword in a sensitivity
list hide a mistake?

Rick

 

[d_s_klein]

I'm not following.  How would using the "all" keyword in a sensitivity
list hide a mistake?

Rick

You said: "I believe the tools will give you warnings about this"

IME, this is not a true statement.

RK

 

[Jan Decaluwe]

You said: "I believe the tools will give you warnings about this"

IME, this is not a true statement.

Are you sure you understand what "all" in a sensitivity list does?

I detect some major misunderstandings in this conversation.

Jan


--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com

 

[Gabor Sz]

You lost me somewhere.  How will this work at all in simulation?

Rick

It won't. The idea is to allow you to build the design in synthesis
without errors. It presumes that your simulator does support the
"all" directive. In synthesis, the sensitivity list is ignored
anyway. I imagine you'd need to make sure that the declaration
for signal "all" does not show up in the code for simulation.

-- Gabor

 

[Gabor Sz]

How is the "all" keyword a hole?  VHDL may be "safe", but so are four
point harnesses and full helmets.  You don't see them used in standard
automobiles, instead we opt for a tradeoff between safety and
convenience.  Forgetting a signal in the sensitivity list of a
combinatorial process (such as a complex case statement) is not an
uncommon mistake.  I believe the tools will give you warnings about
this, but why bother with all that when you can just say "use all
input signals in the sensitivity list... stupid" to the tools?  Where
is the danger?

Rick

It's not clear to me that the simulator will complain about an
incomplete sensitivity list. It should just blithely use the
list it's given. It's the synthesizer that pops up the warnings
about not matching simulation when your list is not complete.
For those who do most of their design work with simulation and
then try to pop off a synthesis at the end of "getting it right"
in simulation, this is a bit late to find out that your design
will not do what you described to the simulator. In this
respect the "all" keyword actually helps prevent problems.
A major issue I have with only seeing a warning during
synthesis and not simulation, is that the synthesis process
is usually rife with warnings that can be safely ignored.
This means I'm more likely to miss the useful ones, like
"incomplete sensitivity list" if I don't also get the
same warning during simulation, where generally speaking
all warnings should be addressed.

My 2 cents,
Gabor

 

[Jonathan Bromley]

if you want to implement the all keyword in your favorite synthesis
tool, you can do it like this:

signal all : std_logic ;

Now you can use

process(all)

in your non-VHDL2008 synthesis tool, and it won't throw errors.

I fear not. 'all' is already a reserved word in every
version of the VHDL standard that I know of. (Think of
"use ieee.std_logic_1164.all;")

Cute idea, though.

 

[KJ]

In order to get around it I've had to add unnecessary registers to my
outputs just so as to be able to use only the clock in the SL, or try to
write the entire thing outside of a process, leading to some serious
verbage nightmares.

Consider using a function (for one output, or a procedure for multiple
outputs) instead. Then the only extra baggage is that of
instantianting the function/procedure call. The code you would've
written in the process simply moves to the function/procedure. If you
forget some input, the compiler complains.

KJ

 

[Paul Uiterlinden]

It's not clear to me that the simulator will complain about an
incomplete sensitivity list. It should just blithely use the
list it's given. It's the synthesizer that pops up the warnings
about not matching simulation when your list is not complete.
For those who do most of their design work with simulation and
then try to pop off a synthesis at the end of "getting it right"
in simulation, this is a bit late to find out that your design
will not do what you described to the simulator. In this
respect the "all" keyword actually helps prevent problems.
A major issue I have with only seeing a warning during
synthesis and not simulation, is that the synthesis process
is usually rife with warnings that can be safely ignored.
This means I'm more likely to miss the useful ones, like
"incomplete sensitivity list" if I don't also get the
same warning during simulation, where generally speaking
all warnings should be addressed.

I fully agree with what you say. Especially when you say that finding out
only at synthesis time about incomplete process sensitivity lists is too
late (*if* you find it at all in the flood of warnings a synthesizer
usually spews out).

That brings me to my 2 euro cents:

1) use a linting tool to catch errors like this in an early stage
2) avoid long sensitivity lists in the first place (as KJ also said)
3) why do synthesis tools spit out so many warnings?
4) synthesis tools should have a setting to make the "incomplete
sensitivity list" warning a fatal

 

[Jan Decaluwe]

I fully agree with what you say. Especially when you say that finding out
only at synthesis time about incomplete process sensitivity lists is too
late (*if* you find it at all in the flood of warnings a synthesizer
usually spews out).

That brings me to my 2 euro cents:

1) use a linting tool to catch errors like this in an early stage

.... or even better: an IDE that flags and offers a quick fix for them
as you are developing (like Sigasi HDT).

2) avoid long sensitivity lists in the first place (as KJ also said)
Yes.

3) why do synthesis tools spit out so many warnings?

4) synthesis tools should have a setting to make the "incomplete
sensitivity list" warning a fatal

Fully agree. To me, this shouldn't even be optional. There is no way how
synthesis can match simulation in such a case, so such code should be
treated as non-synthesizable.

Jan


--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
Analog design automation: http://www.mephisto-da.com
World-class digital design: http://www.easics.com