Why Doesn't VHDL Have a Wildcard Sensitivity List?

Discussion in 'VHDL' started by rickman, Jan 20, 2011.

  1. rickman

    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
     
    rickman, Jan 20, 2011
    #1
    1. Advertising

  2. rickman

    HT-Lab Guest

    "Rob Gaddi" <> wrote in message
    news:...
    > 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
    >
     
    HT-Lab, Jan 20, 2011
    #2
    1. Advertising

  3. 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
     
    Jonathan Bromley, Jan 20, 2011
    #3
  4. rickman

    Gabor Sz Guest

    On Jan 20, 2:33 pm, Jonathan Bromley <>
    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
     
    Gabor Sz, Jan 20, 2011
    #4
  5. 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
     
    Jonathan Bromley, Jan 20, 2011
    #5
  6. rickman

    backhus Guest

    On 21 Jan., 00:33, Jonathan Bromley <>
    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
     
    backhus, Jan 21, 2011
    #6
  7. rickman

    HT-Lab Guest

    "HT-Lab" <> wrote in message
    news:X2_Zo.3326$2...
    >
    > "Rob Gaddi" <> wrote in message
    > news:...
    >> 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
     
    HT-Lab, Jan 21, 2011
    #7
  8. rickman

    rickman Guest

    On Jan 21, 2:37 am, backhus <> wrote:
    > On 21 Jan., 00:33, Jonathan Bromley <>
    > 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
     
    rickman, Jan 21, 2011
    #8
  9. rickman

    Walter Guest

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

    Walter



    --- news://freenews.netfront.net/ - complaints: ---
     
    Walter, Jan 21, 2011
    #9
  10. rickman

    d_s_klein Guest

    On Jan 21, 8:17 am, Walter <> wrote:
    > VHDL is a reasonably safe hardware description language; why we insist
    > on make holes over the bridge ?
    >
    > Walter
    >
    > --- news://freenews.netfront.net/ - complaints: ---


    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
     
    d_s_klein, Jan 21, 2011
    #10
  11. rickman

    rickman Guest

    On Jan 21, 11:17 am, Walter <> wrote:
    > VHDL is a reasonably safe hardware description language; why we insist
    > on make holes over the bridge ?
    >
    > Walter
    >
    > --- news://freenews.netfront.net/ - complaints: ---


    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, Jan 21, 2011
    #11
  12. rickman

    rickman Guest

    On Jan 21, 11:38 am, d_s_klein <> wrote:
    > On Jan 21, 8:17 am, Walter <> wrote:
    >
    > > VHDL is a reasonably safe hardware description language; why we insist
    > > on make holes over the bridge ?

    >
    > > Walter

    >
    > > --- news://freenews.netfront.net/ - complaints: ---

    >
    > 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
     
    rickman, Jan 21, 2011
    #12
  13. rickman

    d_s_klein Guest

    On Jan 21, 9:26 am, rickman <> wrote:
    > On Jan 21, 11:38 am, d_s_klein <> wrote:
    >
    >
    >
    > > On Jan 21, 8:17 am, Walter <> wrote:

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

    >
    > > > Walter

    >
    > > > --- news://freenews.netfront.net/ - complaints: ---

    >
    > > 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.

    RK
     
    d_s_klein, Jan 21, 2011
    #13
  14. rickman

    Jan Decaluwe Guest

    d_s_klein wrote:
    > On Jan 21, 9:26 am, rickman <> wrote:
    >> On Jan 21, 11:38 am, d_s_klein <> wrote:
    >>
    >>
    >>
    >>> On Jan 21, 8:17 am, Walter <> wrote:
    >>>> VHDL is a reasonably safe hardware description language; why we insist
    >>>> on make holes over the bridge ?
    >>>> Walter
    >>>> --- news://freenews.netfront.net/ - complaints: ---
    >>> 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.


    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
     
    Jan Decaluwe, Jan 21, 2011
    #14
  15. rickman

    Gabor Sz Guest

    On Jan 21, 10:17 am, rickman <> wrote:
    > On Jan 21, 2:37 am, backhus <> wrote:
    >
    >
    >
    > > On 21 Jan., 00:33, Jonathan Bromley <>
    > > 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


    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, Jan 21, 2011
    #15
  16. rickman

    Gabor Sz Guest

    On Jan 21, 12:25 pm, rickman <> wrote:
    > On Jan 21, 11:17 am, Walter <> wrote:
    >
    > > VHDL is a reasonably safe hardware description language; why we insist
    > > on make holes over the bridge ?

    >
    > > Walter

    >
    > > --- news://freenews.netfront.net/ - complaints: ---

    >
    > 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
     
    Gabor Sz, Jan 21, 2011
    #16
  17. 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.


    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
     
    Jonathan Bromley, Jan 21, 2011
    #17
  18. rickman

    KJ Guest

    On Jan 21, 12:28 pm, Rob Gaddi <> wrote:

    >
    > 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
     
    KJ, Jan 21, 2011
    #18
  19. 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.


    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.
     
    Paul Uiterlinden, Jan 21, 2011
    #19
  20. rickman

    Jan Decaluwe Guest

    Paul Uiterlinden wrote:
    > 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.

    >
    > 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
     
    Jan Decaluwe, Jan 22, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. walala
    Replies:
    3
    Views:
    749
    Allan Herriman
    Sep 9, 2003
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,005
    Smokey Grindel
    Dec 2, 2006
  3. omara007
    Replies:
    0
    Views:
    1,481
    omara007
    Jan 6, 2010
  4. Replies:
    7
    Views:
    842
  5. westocl
    Replies:
    4
    Views:
    1,965
    joris
    Mar 17, 2011
Loading...

Share This Page