Why Doesn't VHDL Have a Wildcard Sensitivity List?

R

rickman

Guest
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
Click to expand...
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
 
"Rob Gaddi" <rgaddi@technologyhighland.com> wrote in message
news:s82dnYG3SLRV9qXQnZ2dnUVZ_vudnZ2d@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.
Click to expand...
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.
Click to expand...
Precision and Synplify and I believe QNS (not 100% sure),

Hans
www.ht-lab.com

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Click to expand...
 
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?
Click to expand...
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.
Click to expand...
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
 
On Jan 20, 2:33 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
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
Click to expand...
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
 
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
Click to expand...
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" <hans64@ht-lab.com> wrote in message
news:X2_Zo.3326$S16.1073@newsfe20.ams2...
"Rob Gaddi" <rgaddi@technologyhighland.com> wrote in message
news:s82dnYG3SLRV9qXQnZ2dnUVZ_vudnZ2d@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),
Click to expand...
QNS (Quartus 10.1) supports it as well, XST(ISE 12.3) does not.

Hans
www.ht-lab.com
 
On Jan 21, 2:37 am, backhus <goous...@googlemail.com> wrote:
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.
Click to expand...
You lost me somewhere. How will this work at all in simulation?

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

Walter



--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
On 1/21/2011 8:38 AM, d_s_klein 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.

RK
Click to expand...
Whereas I find the sensitivity lists on large combinational processes to
be one of the serious banes of my VHDL existence. I've lost untold
hours to trying to figure out why one input to, for instance, a 16:1 mux
with multi-part enable, wasn't getting updated properly, only to find
that I had forgotten it in the 17+ element long sensitivity list.

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.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
 
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 ---
Click to expand...
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
 
On Jan 21, 11: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 ---
Click to expand...
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
 
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.
Click to expand...
I'm not following. How would using the "all" keyword in a sensitivity
list hide a mistake?

Rick
 
d_s_klein wrote:
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.
Click to expand...
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
 
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
Click to expand...
You said: "I believe the tools will give you warnings about this"

IME, this is not a true statement.

RK
 
On Thu, 20 Jan 2011 23:37:50 -0800 (PST), backhus wrote:

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.
Click to expand...
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.
--
Jonathan Bromley
 
On Jan 21, 10:17 am, rickman <gnu...@gmail.com> wrote:
On Jan 21, 2:37 am, backhus <goous...@googlemail.com> wrote:



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.

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

Rick
Click to expand...
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
 
On Jan 21, 12:25 pm, rickman <gnu...@gmail.com> wrote:
On Jan 21, 11: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 ---

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
Click to expand...
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
 
Gabor Sz wrote:

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.
Click to expand...
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

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top