Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Why Doesn't VHDL Have a Wildcard Sensitivity List?

Reply
Thread Tools

Why Doesn't VHDL Have a Wildcard Sensitivity List?

 
 
rickman
Guest
Posts: n/a
 
      01-20-2011
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
 
Reply With Quote
 
 
 
 
HT-Lab
Guest
Posts: n/a
 
      01-20-2011

"Rob Gaddi" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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),

Hans
www.ht-lab.com

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



 
Reply With Quote
 
 
 
 
Jonathan Bromley
Guest
Posts: n/a
 
      01-20-2011
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
 
Reply With Quote
 
Gabor Sz
Guest
Posts: n/a
 
      01-20-2011
On Jan 20, 2:33*pm, Jonathan Bromley <(E-Mail Removed)>
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


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
 
Reply With Quote
 
Jonathan Bromley
Guest
Posts: n/a
 
      01-20-2011
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
 
Reply With Quote
 
backhus
Guest
Posts: n/a
 
      01-21-2011
On 21 Jan., 00:33, Jonathan Bromley <(E-Mail Removed)>
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.

Have a nice synthesis
Eilert
 
Reply With Quote
 
HT-Lab
Guest
Posts: n/a
 
      01-21-2011

"HT-Lab" <(E-Mail Removed)> wrote in message
news:X2_Zo.3326$(E-Mail Removed)2...
>
> "Rob Gaddi" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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),


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

Hans
www.ht-lab.com


 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      01-21-2011
On Jan 21, 2:37*am, backhus <(E-Mail Removed)> wrote:
> On 21 Jan., 00:33, Jonathan Bromley <(E-Mail Removed)>
> 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
 
Reply With Quote
 
Walter
Guest
Posts: n/a
 
      01-21-2011

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

Walter



--- news://freenews.netfront.net/ - complaints: http://www.velocityreviews.com/forums/(E-Mail Removed) ---
 
Reply With Quote
 
d_s_klein
Guest
Posts: n/a
 
      01-21-2011
On Jan 21, 8:17*am, Walter <(E-Mail Removed)> wrote:
> 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 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
VHDL Sensitivity (Clock Delay Question) westocl VHDL 4 03-17-2011 11:35 AM
Wildcard String Comparisons: Set Pattern to a Wildcard Source chaoticcranium@gmail.com Python 7 10-05-2010 09:26 PM
Emacs VHDL-Mode Problem : vhdl-update-sensitivity-process omara007 VHDL 0 01-06-2010 03:47 AM
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM



Advertisments