Why Doesn't VHDL Have a Wildcard Sensitivity List?

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

On 1/20/2011 9:02 AM, rickman wrote:
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

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

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

--
Rob Gaddi, Highland Technology
Email address is currently out of order

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?

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.

On Thu, 20 Jan 2011 09:02:47 -0800 (PST), rickman wrote:
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?
--
Jonathan Bromley

On Thu, 20 Jan 2011 14:52:34 -0800 (PST), Gabor Sz wrote:
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
--
Jonathan Bromley

"Rob Gaddi" <rgaddi_at_technologyhighland.com> wrote in message
news:s82dnYG3SLRV9qXQnZ2dnUVZ_vudnZ2d_at_lmi.net...
On 1/20/2011 9:02 AM, rickman wrote:
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

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),

On 21 Jan., 00:33, Jonathan Bromley <s...@oxfordbromley.plus.com
wrote:



On Thu, 20 Jan 2011 14:52:34 -0800 (PST), Gabor Sz wrote:
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
--
Jonathan Bromley

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.

On Jan 21, 8:17 am, Walter<wsf...@adinet.com.uy> wrote:
VHDL is a reasonably safe hardware description language; why we insist
on make holes over the bridge ?

Walter

--- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

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

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

Walter

--- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

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

Walter

--- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

On Jan 21, 8:17 am, Walter <wsf...@adinet.com.uy> wrote:

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

Walter

--- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

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.

On Jan 21, 9:26 am, rickman <gnu...@gmail.com> wrote:
On Jan 21, 11:38 am, d_s_klein <d_s_kl...@yahoo.com> wrote:



On Jan 21, 8:17 am, Walter <wsf...@adinet.com.uy> wrote:
VHDL is a reasonably safe hardware description language; why we insist
on make holes over the bridge ?
Walter
--- news://freenews.netfront.net/ - complaints: n...@netfront.net ---
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

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

IME, this is not a true statement.