Null statement in VHDL

Discussion in 'VHDL' started by Weng Tianxiang, Aug 27, 2007.

  1. Hi,
    I rarely use null statement in my designs.

    I check the definition of null statement from book "HDL Chip Design"
    written by Douglas J. Smith. It says that "Performs no action. Has no
    other effect other than to pass execution on to the next sequential
    statement."

    I have two questions:
    1. Based on my experiences with VHDL, the following 3 designs should
    be the same.

    State_A is a state machine signal.

    A1 : process(RESET, CLK)
    begin
    if(RESET = '1') then
    State_A <= State_0_S;
    elsif(CLK'event and CLK = '1') then
    case State_A is
    when State_0_S =>
    if(A = '1') then
    State_A <= State_1_S;
    else
    State_A <= State_0_S;
    end if;
    ...
    ...
    end case;
    end if;
    end process;

    A2 : process(RESET, CLK)
    begin
    if(RESET = '1') then
    State_A <= State_0_S;
    elsif(CLK'event and CLK = '1') then
    case State_A is
    when State_0_S =>
    if(A = '1') then
    State_A <= State_1_S;
    else
    null;
    end if;
    ...
    ...
    end case;
    end if;
    end process;

    A3 : process(RESET, CLK)
    begin
    if(RESET = '1') then
    State_A <= State_0_S;
    elsif(CLK'event and CLK = '1') then
    case State_A is
    when State_0_S =>
    if(A = '1') then
    State_A <= State_1_S;
    end if;
    ...
    ...
    end case;
    end if;
    end process;

    2. Where can I download the latest version of VHDL language definition
    (83, 90 2000)?

    Any comments are welcome.

    Thank you.

    Weng
     
    Weng Tianxiang, Aug 27, 2007
    #1
    1. Advertising

  2. Weng Tianxiang wrote:

    > I rarely use null statement in my designs.


    They sometimes make a nice placeholder for a comment:

    ...
    else
    null; -- future: enable explosive bolts here.
    end if;

    > I have two questions:
    > 1. Based on my experiences with VHDL, the following 3 designs should
    > be the same.


    Yes. What's the question?

    > 2. Where can I download the latest version of VHDL language definition
    > (83, 90 2000)?


    http://www.ieee.org/web/standards/home/index.html

    -- Mike Treseler
     
    Mike Treseler, Aug 27, 2007
    #2
    1. Advertising

  3. On Aug 27, 10:37 am, Mike Treseler <> wrote:
    > Weng Tianxiang wrote:
    > > I rarely use null statement in my designs.

    >
    > They sometimes make a nice placeholder for a comment:
    >
    > ...
    > else
    > null; -- future: enable explosive bolts here.
    > end if;
    >
    > > I have two questions:
    > > 1. Based on my experiences with VHDL, the following 3 designs should
    > > be the same.

    >
    > Yes. What's the question?
    >
    > > 2. Where can I download the latest version of VHDL language definition
    > > (83, 90 2000)?

    >
    > http://www.ieee.org/web/standards/home/index.html
    >
    > -- Mike Treseler


    Hi Mike,
    Thank you.

    It seems to me that I should buy a VHDL standard book (I've never have
    it).

    93 or 2000 or 2002? Any suggestions?

    Weng
     
    Weng Tianxiang, Aug 27, 2007
    #3
  4. Weng Tianxiang wrote:

    > It seems to me that I should buy a VHDL standard book (I've never have
    > it).
    >
    > 93 or 2000 or 2002? Any suggestions?


    Get the latest available, but
    I would get a copy of Ashenden,
    a good vhdl simulator,
    and master those first.

    -- Mike Treseler
     
    Mike Treseler, Aug 27, 2007
    #4
  5. Weng Tianxiang

    Mike Lundy Guest

    > It seems to me that I should buy a VHDL standard book (I've never have
    > it).
    >
    > 93 or 2000 or 2002? Any suggestions?


    This is going to sound awful, but I'd actually recommend for your
    mental health that you not look too deeply at the actual standards.
    Instead, read about the synthesizers themselves. None of the VHDL
    synthesizers I've tried completely implement any version of the
    standard. Instead, they implement odd hybrids of the different
    versions of the standard, on the grounds that "no one uses this
    feature" (well, of course! No one uses it because it doesn't work in
    your popular product!)

    I get really frustrated when I try to implement something using
    standard VHDL and find that it is incorrectly or incompletely
    supported. I wish more people would have higher standards with the
    software they use. The way I see it, it's false advertising to
    advertise something as a VHDL synthesizer if it doesn't completely
    implement the VHDL standard, but not many seem to agree with me.

    I think it comes down to the difference between engineers and
    scientists. Scientists prefer theory, and deviations from the ideal
    grate on us. Engineers prefer practicality, and will tend to solder on
    (pun intended) through crappy software, more interested in the end
    result than the process. I have grounding in both, so I complain as I
    implement, and depend less on crappy software whenever the chance
    presents itself. Life's too short for bad software.
     
    Mike Lundy, Aug 27, 2007
    #5
  6. On Aug 27, 11:33 am, Mike Lundy <> wrote:
    > > It seems to me that I should buy a VHDL standard book (I've never have
    > > it).

    >
    > > 93 or 2000 or 2002? Any suggestions?

    >
    > This is going to sound awful, but I'd actually recommend for your
    > mental health that you not look too deeply at the actual standards.
    > Instead, read about the synthesizers themselves. None of the VHDL
    > synthesizers I've tried completely implement any version of the
    > standard. Instead, they implement odd hybrids of the different
    > versions of the standard, on the grounds that "no one uses this
    > feature" (well, of course! No one uses it because it doesn't work in
    > your popular product!)
    >
    > I get really frustrated when I try to implement something using
    > standard VHDL and find that it is incorrectly or incompletely
    > supported. I wish more people would have higher standards with the
    > software they use. The way I see it, it's false advertising to
    > advertise something as a VHDL synthesizer if it doesn't completely
    > implement the VHDL standard, but not many seem to agree with me.
    >
    > I think it comes down to the difference between engineers and
    > scientists. Scientists prefer theory, and deviations from the ideal
    > grate on us. Engineers prefer practicality, and will tend to solder on
    > (pun intended) through crappy software, more interested in the end
    > result than the process. I have grounding in both, so I complain as I
    > implement, and depend less on crappy software whenever the chance
    > presents itself. Life's too short for bad software.


    Hi Mike,
    "None of the VHDL
    synthesizers I've tried completely implement any version of the
    standard. Instead, they implement odd hybrids of the different
    versions of the standard"

    Your comments are interesting and funny !!!

    There are a lot of definitions I have difficulty to learn so that I
    have never used them and have never tried them.

    For example, sharing a signal, block concept and the latest ones that
    do formal verification are a few features I have never used and tried.

    I prefer using a very small set of the definitions and the strategy
    works well.

    One thing I miss a lot is 'orif' keyword compared to 'elsif'.

    'orif' introduces a group of conditions that are mutually exclusive.

    On any output buses or input buses, all data running on the buses are
    mutually exclusive.

    I couldn't persuade James to change his mind.

    Weng
     
    Weng Tianxiang, Aug 27, 2007
    #6
  7. Weng Tianxiang

    Alex Colvin Guest

    >It seems to me that I should buy a VHDL standard book (I've never have
    >it).


    >93 or 2000 or 2002? Any suggestions?


    whichever standard (or mix thereof) is supported by the software you
    expect to use. just because it's in the book doesn't mean it works.

    --
    mac the naïf
     
    Alex Colvin, Aug 27, 2007
    #7
  8. Weng Tianxiang

    Andy Guest

    On Aug 27, 1:33 pm, Mike Lundy <> wrote:
    > > It seems to me that I should buy a VHDL standard book (I've never have
    > > it).

    >
    > > 93 or 2000 or 2002? Any suggestions?

    >
    > This is going to sound awful, but I'd actually recommend for your
    > mental health that you not look too deeply at the actual standards.
    > Instead, read about the synthesizers themselves. None of the VHDL
    > synthesizers I've tried completely implement any version of the
    > standard. Instead, they implement odd hybrids of the different
    > versions of the standard, on the grounds that "no one uses this
    > feature" (well, of course! No one uses it because it doesn't work in
    > your popular product!)
    >
    > I get really frustrated when I try to implement something using
    > standard VHDL and find that it is incorrectly or incompletely
    > supported. I wish more people would have higher standards with the
    > software they use. The way I see it, it's false advertising to
    > advertise something as a VHDL synthesizer if it doesn't completely
    > implement the VHDL standard, but not many seem to agree with me.
    >
    > I think it comes down to the difference between engineers and
    > scientists. Scientists prefer theory, and deviations from the ideal
    > grate on us. Engineers prefer practicality, and will tend to solder on
    > (pun intended) through crappy software, more interested in the end
    > result than the process. I have grounding in both, so I complain as I
    > implement, and depend less on crappy software whenever the chance
    > presents itself. Life's too short for bad software.


    Mike,

    I share your frustrations, but with a little common sense, most
    limitations of synthesis are understandable. For instance, time delays
    (independent of a clock, i.e. "after 5 ns") are meaningless to most
    synthesizable targets, because there is no ability to accurately
    implement them. File IO is another (although pre-elaboration level
    file IO, e.g. using a file to initialize a constant, should be allowed
    but is not). After all, vhdl is a technology-independent, descriptive
    language; naturally, there will be some aspects of the language that
    do not map to certain technology targets.

    Then there are things like no deferred constants in synthesis still
    bother me, because there is no good reason for the limitation. Most
    synthesis tools do not support global signals either.

    There is an ieee standard for the "minimum" synthesizable subset of
    vhdl, but its creation was dominated by the big player(s) in
    synthesis, and focused on what they had already implemented. Since
    then, updates to the standard have been few and far between, and the
    standard has also migrated from a template based approach, to a
    behavioral approach. The tool vendors (some more responsive than
    others to customer's needs) have since implemented parts of vhdl not
    handled in the synthesis standard. In some ways, this accelerates the
    adoption of new features (due to competition), but it also leads to
    diversity of capabilities across vendors, requiring a minimum "least
    common denominator" approach to coding for multiple synthesis vendors.
    The only way to raise the least common denominator is by refusing to
    buy/use products that fail to keep up with the competition (so they
    fall out of the business, like synopsys fpga synthesis), or revising
    the standards (and refusing to buy/use products that don't adhere to
    the standard). Since both require market response, the standards
    effort is less meaningful, and has lapsed behind.

    Andy
     
    Andy, Aug 27, 2007
    #8
  9. Weng Tianxiang

    Andy Guest

    On Aug 27, 2:32 pm, Weng Tianxiang <> wrote:
    > On Aug 27, 11:33 am, Mike Lundy <> wrote:
    >
    >
    >
    > > > It seems to me that I should buy a VHDL standard book (I've never have
    > > > it).

    >
    > > > 93 or 2000 or 2002? Any suggestions?

    >
    > > This is going to sound awful, but I'd actually recommend for your
    > > mental health that you not look too deeply at the actual standards.
    > > Instead, read about the synthesizers themselves. None of the VHDL
    > > synthesizers I've tried completely implement any version of the
    > > standard. Instead, they implement odd hybrids of the different
    > > versions of the standard, on the grounds that "no one uses this
    > > feature" (well, of course! No one uses it because it doesn't work in
    > > your popular product!)

    >
    > > I get really frustrated when I try to implement something using
    > > standard VHDL and find that it is incorrectly or incompletely
    > > supported. I wish more people would have higher standards with the
    > > software they use. The way I see it, it's false advertising to
    > > advertise something as a VHDL synthesizer if it doesn't completely
    > > implement the VHDL standard, but not many seem to agree with me.

    >
    > > I think it comes down to the difference between engineers and
    > > scientists. Scientists prefer theory, and deviations from the ideal
    > > grate on us. Engineers prefer practicality, and will tend to solder on
    > > (pun intended) through crappy software, more interested in the end
    > > result than the process. I have grounding in both, so I complain as I
    > > implement, and depend less on crappy software whenever the chance
    > > presents itself. Life's too short for bad software.

    >
    > Hi Mike,
    > "None of the VHDL
    > synthesizers I've tried completely implement any version of the
    > standard. Instead, they implement odd hybrids of the different
    > versions of the standard"
    >
    > Your comments are interesting and funny !!!
    >
    > There are a lot of definitions I have difficulty to learn so that I
    > have never used them and have never tried them.
    >
    > For example, sharing a signal, block concept and the latest ones that
    > do formal verification are a few features I have never used and tried.
    >
    > I prefer using a very small set of the definitions and the strategy
    > works well.
    >
    > One thing I miss a lot is 'orif' keyword compared to 'elsif'.
    >
    > 'orif' introduces a group of conditions that are mutually exclusive.
    >
    > On any output buses or input buses, all data running on the buses are
    > mutually exclusive.
    >
    > I couldn't persuade James to change his mind.
    >
    > Weng


    Weng,

    What would happen in a simulator if the "orif" conditions were not
    actually mutually exclusive? How would you allow the user to define
    said behavior? Is zero-hot and option, or is one-hot guaranteed? How
    would the user define that?

    The existing language allows for mutually exclusive conditions, but
    said conditions must be statically verifiable as mutex and complete
    (case statements). For dynamic mutex inputs, verification is best
    handled in an assertion. If a standardized one_hot() or zero_one_hot()
    function could be created (to operate on an unconstrained vector of
    booleans, for example), then synthesis could recognize their use in an
    assertion, and make the appropriate optimizations automatically,
    without affecting the syntax or structure of the language. The
    assertion (or other code) could also control what happens when, in
    fact, the conditions are not mutually exclusive (the same way the
    language handles indices out of bounds, etc.). In other words, in
    order to gain that level of control over what happens if mutex is not
    true, you'd have to use the same amount of code for either solution,
    and the latter solution does not require a change to the language.
    Additionally, the use of an assertion is such an application allows
    the code more flexibility in describing the resulting behavior,
    without resulting to a single if-orif tree. Simply tell the synthesis
    tool that, by the way, x and y are one_hot, and it can make
    optimizations (like sharing resources) efficiently, independent of the
    rest of the structure.

    Finally, "orif" would be a very poor choice for such a keyword, even
    if the feature were a good idea. "Orif" by name implies that multiple
    conditions are potentially true (logical 'OR' function), and all
    statements associated with all true conditions would be executed,
    which is precisely the opposite of what you described. This behavior
    is equivalent to multiple, non-nested if-then statements.

    Andy
     
    Andy, Aug 27, 2007
    #9
  10. Weng Tianxiang

    Mike Lundy Guest

    On Aug 27, 3:09 pm, Andy <> wrote:
    > Mike,
    >
    > I share your frustrations, but with a little common sense, most
    > limitations of synthesis are understandable. For instance, time delays
    > (independent of a clock, i.e. "after 5 ns") are meaningless to most
    > synthesizable targets, because there is no ability to accurately
    > implement them. File IO is another (although pre-elaboration level
    > file IO, e.g. using a file to initialize a constant, should be allowed
    > but is not). After all, vhdl is a technology-independent, descriptive
    > language; naturally, there will be some aspects of the language that
    > do not map to certain technology targets.


    All true, but remember, I'm complaining about difference between the
    standard and what companies implement, not the vhdl standard itself.
    The differences between synthesis and simulation modes (while a tad
    murky in the standard itself) are perfectly understandable, given both
    the nature of the output, and vhdl's history.

    A side note: I'm amused by the parallels between Lisp's development
    and VHDL's. Both started as documentation formats (... more or less)
    that someone decided to write an interpreter for.

    > Then there are things like no deferred constants in synthesis still
    > bother me, because there is no good reason for the limitation. Most
    > synthesis tools do not support global signals either.


    Yeah, both of those bug me. It's so difficult to achieve truly
    universal constants in a design.

    > There is an ieee standard for the "minimum" synthesizable subset of
    > vhdl, but its creation was dominated by the big player(s) in
    > synthesis, and focused on what they had already implemented. Since
    > then, updates to the standard have been few and far between, and the
    > standard has also migrated from a template based approach, to a
    > behavioral approach. The tool vendors (some more responsive than
    > others to customer's needs) have since implemented parts of vhdl not
    > handled in the synthesis standard. In some ways, this accelerates the
    > adoption of new features (due to competition), but it also leads to
    > diversity of capabilities across vendors, requiring a minimum "least
    > common denominator" approach to coding for multiple synthesis vendors.
    > The only way to raise the least common denominator is by refusing to
    > buy/use products that fail to keep up with the competition (so they
    > fall out of the business, like synopsys fpga synthesis), or revising
    > the standards (and refusing to buy/use products that don't adhere to
    > the standard). Since both require market response, the standards
    > effort is less meaningful, and has lapsed behind.


    That's pretty much my point, yeah. People need to stop allowing
    companies to shovel crap. Don't buy it if it's crap. If it only
    implements 1/2 of the standard, let's call it a VH synthisizer
    instead :p. If you absolutely must buy it (gotta get the product out,
    after all, even if you have to compromise your values to do so...)
    then raise a huge stink about how bad the software is. Report every
    bug you come across. Publicize the worst of them if the vendor still
    doesn't fix them. Just don't settle for the status quo.

    C compilers eventually came out of the dark ages. It would be
    excellent if VHDL synthesizers could do the same.
     
    Mike Lundy, Aug 27, 2007
    #10
  11. On 28 Aug., 00:09, Andy <> wrote:
    > On Aug 27, 1:33 pm, Mike Lundy <> wrote:
    >
    >
    >
    > > > It seems to me that I should buy a VHDL standard book (I've never have
    > > > it).

    >
    > > > 93 or 2000 or 2002? Any suggestions?

    >
    > > This is going to sound awful, but I'd actually recommend for your
    > > mental health that you not look too deeply at the actual standards.
    > > Instead, read about the synthesizers themselves. None of the VHDL
    > > synthesizers I've tried completely implement any version of the
    > > standard. Instead, they implement odd hybrids of the different
    > > versions of the standard, on the grounds that "no one uses this
    > > feature" (well, of course! No one uses it because it doesn't work in
    > > your popular product!)

    >
    > > I get really frustrated when I try to implement something using
    > > standard VHDL and find that it is incorrectly or incompletely
    > > supported. I wish more people would have higher standards with the
    > > software they use. The way I see it, it's false advertising to
    > > advertise something as a VHDL synthesizer if it doesn't completely
    > > implement the VHDL standard, but not many seem to agree with me.

    >
    > > I think it comes down to the difference between engineers and
    > > scientists. Scientists prefer theory, and deviations from the ideal
    > > grate on us. Engineers prefer practicality, and will tend to solder on
    > > (pun intended) through crappy software, more interested in the end
    > > result than the process. I have grounding in both, so I complain as I
    > > implement, and depend less on crappy software whenever the chance
    > > presents itself. Life's too short for bad software.

    >
    > Mike,
    >
    > I share your frustrations, but with a little common sense, most
    > limitations of synthesis are understandable. For instance, time delays
    > (independent of a clock, i.e. "after 5 ns") are meaningless to most
    > synthesizable targets, because there is no ability to accurately
    > implement them. File IO is another (although pre-elaboration level
    > file IO, e.g. using a file to initialize a constant, should be allowed
    > but is not). After all, vhdl is a technology-independent, descriptive
    > language; naturally, there will be some aspects of the language that
    > do not map to certain technology targets.
    >
    > Then there are things like no deferred constants in synthesis still
    > bother me, because there is no good reason for the limitation. Most
    > synthesis tools do not support global signals either.


    The frustrating thing is, that there are papers out there that show
    how simple
    it is to greatly expanded the synthesizable subset.

    Some examples:

    The following code can be made synthesizable by a simple vhdl->vhdl
    transformation. A preprocessor would suffice:
    if rising_edge(clk) and enable='1' then ...

    Why is there only a single wait statement allowed per process? If all
    wait statements depend on the same clock signal it is relativly easy
    to automatically create a state machine with one state per wait
    statement.

    What is so hard about replacing "/" by a division circuit? Especially
    for a tool that is
    delivered with a core generator that supports division? Especially for
    division by a constant (can be implemented by a multiplier, yet
    multiplication is supported)?

    At least most tools now recognize initialization values for signals.
    Took them only 20 years to implement that.


    My frustration comes from work in the EDA software field. I see that
    really hard tasks that are solved successfully during the synthesis
    and implementation process and wonder why topics like those above or
    not handled well, even though they are a lot simpler.

    Kolja Sulimma
     
    comp.arch.fpga, Aug 28, 2007
    #11
  12. Weng Tianxiang

    HT-Lab Guest

    "comp.arch.fpga" <> wrote in message
    news:...
    > On 28 Aug., 00:09, Andy <> wrote:
    >> On Aug 27, 1:33 pm, Mike Lundy <> wrote:
    >>

    ...snip
    >>
    >> Then there are things like no deferred constants in synthesis still
    >> bother me, because there is no good reason for the limitation. Most
    >> synthesis tools do not support global signals either.

    >
    > The frustrating thing is, that there are papers out there that show
    > how simple
    > it is to greatly expanded the synthesizable subset.
    >
    > Some examples:
    >
    > The following code can be made synthesizable by a simple vhdl->vhdl
    > transformation. A preprocessor would suffice:
    > if rising_edge(clk) and enable='1' then ...


    Gated clocks are supported by most high-end synthesis tools.

    >
    > Why is there only a single wait statement allowed per process? If all
    > wait statements depend on the same clock signal it is relativly easy
    > to automatically create a state machine with one state per wait
    > statement.


    Precision supports multiple wait statement per process provided, as you
    mention they use the same clock, from the manual:

    "Multiple wait statements are supported in a process with some synthesis
    restrictions. All the control paths should have at least one wait statement
    and all of the wait statements should be identical with a single bit clock
    expression.

    The expression in the until condition must specify a leading or falling
    single clock edge. All assignments inside the process result in the creation
    of registers. Each register (flip-flop) is clocked with the single clock
    signal.

    There are a number of cases where multiple waits are synthesizable and
    resemble statemachine behavior. In Precision RTL Synthesis, multiple waits
    are supported".

    process -- no sensitivity list
    begin
    wait until clk' event AND clk='1';
    output_signal <= 0;
    while (input_signal < 6) loop
    wait until clk' event AND clk='1';
    output_signal <= output_signal +1;
    end loop;
    end process;


    > What is so hard about replacing "/" by a division circuit? Especially
    > for a tool that is
    > delivered with a core generator that supports division? Especially for
    > division by a constant (can be implemented by a multiplier, yet
    > multiplication is supported)?


    I agree, not sure what the reason is.

    >
    > At least most tools now recognize initialization values for signals.
    > Took them only 20 years to implement that.


    This might work for Xilinx which can initialise a register from the
    bitstream, however, what would happen if you use this design on a ASIC or
    FPGA that doesn't support this (e.g. Actel). I am all in favour of
    technology independent code and inferring as much as possible, makes life so
    much easier for the next guy to pick up your code :)

    Hans
    www.ht-lab.com


    >
    >
    > My frustration comes from work in the EDA software field. I see that
    > really hard tasks that are solved successfully during the synthesis
    > and implementation process and wonder why topics like those above or
    > not handled well, even though they are a lot simpler.
    >
    > Kolja Sulimma
    >
    >
    >
    >
    >
    >
     
    HT-Lab, Aug 28, 2007
    #12
  13. On 28 Aug., 10:27, "HT-Lab" <> wrote:
    > "comp.arch.fpga" <> wrote in message
    > > At least most tools now recognize initialization values for signals.
    > > Took them only 20 years to implement that.

    >
    > This might work for Xilinx which can initialise a register from the
    > bitstream, however, what would happen if you use this design on a ASIC or
    > FPGA that doesn't support this (e.g. Actel). I am all in favour of
    > technology independent code and inferring as much as possible, makes life so
    > much easier for the next guy to pick up your code :)


    I believe that's similar to instantiating 10 millon gates in a device
    that only supports
    5 million gates or stating a 500MHz constraint when only 250 are
    possible.
    The tool should tell you the reason why it can't be done.

    Excludig a feature because a small portion of technologies can't
    support it is not wise.
    Especially in a case like the reset values were you get a simulation
    mismatch because of
    the omission.

    Kolja Sulimma
     
    comp.arch.fpga, Aug 28, 2007
    #13
  14. On 2007-08-27, Mike Treseler <> wrote:

    |------------------------------------------------------------------------|
    |"[..] |
    | |
    |> I have two questions: |
    |> 1. Based on my experiences with VHDL, the following 3 designs should |
    |> be the same. |
    | |
    |Yes. [..] |
    | |
    |[..]" |
    |------------------------------------------------------------------------|

    I disagree.

    A2 is equivalent to A3.

    A1 and A2 could be equivalent, but not necessarily. In A1, State_A has
    the value State_0_S and is assigned the value it already has. Instead
    of that assignment, A2 has a null statement. However, A1 is not
    necessarily equivalent to A2 if:
    A2 could be running with another process which is assigning any other
    value to State_A;
    or
    the assignment State_A <= State_0_S; could delete previously computed
    transactions from the projected output waveform.

    Regards,
    Colin Paul Gloster
     
    Colin Paul Gloster, Aug 28, 2007
    #14
  15. I apologize if almost the same response as this is received. I had
    typed a response which I thought I posted over an hour ago but it does
    not seem to appear even on the server I originally had posted it on,
    so I retype a response and I try a different client and server.

    In news:
    timestamped Tue, 28 Aug 2007 07:45:18 -0000,
    "comp.arch.fpga" <> posted:
    |----------------------------------------------------------------------------|
    |"[..] |
    | |
    |At least most tools now recognize initialization values for signals." |
    |----------------------------------------------------------------------------|

    Synopsys Presto VHDL does not, according to what is documented on Page
    C-5 of
    sold/doc/online/dc/pvhdl/pvhdl_c.pdf
    for Version Y-2006.06. Which synthesis tools do support initialization
    of signals?

    |----------------------------------------------------------------------------|
    |"Took them only 20 years to implement that. |
    | |
    | |
    |My frustration comes from work in the EDA software field. I see that |
    |really hard tasks that are solved successfully during the synthesis |
    |and implementation process and wonder why topics like those above or |
    |not handled well, even though they are a lot simpler. |
    | |
    |Kolja Sulimma" |
    |----------------------------------------------------------------------------|

    Perhaps because they are too lazy to implement features which
    customers can easily be led to believe are frills? E.g. Jonathan
    Bromley posted on 2007 March 5th:
    "[..]

    [..] The majority of
    hardware platforms do not offer reliable power-up
    initialisation of internal state. Consequently it is appropriate
    to code explicitly some reset behaviour. For exactly this
    reason, the hardware-oriented data types in VHDL (std_logic,
    etc) have a specific undefined value as the leftmost value
    of their value-set, so that initialisation oversights are
    more likely to be detected.


    Unfortunately for a purist such as you, there are many
    occasions in hardware design where it is entirely
    appropriate to read an uninitialised object. For
    example, a pipeline or shift register probably does
    not need the hardware overhead of reset; it will
    automatically flush itself out over the first few clock
    cycles - but only if you allow it to run, which of course
    entails reading uninitialised (or default-initialised) values.
    Consequently it is appropriate for synthesis tools to do
    pretty much what they generally do: don't worry about
    initialisations. For preference, they should issue warnings
    about attempts to do explicit initialisation, since these cannot
    be synthesised to hardware on most platforms. However,
    even then it may be appropriate to let this past, since the
    explicit initialisation may be useful in order to limit the
    excessive pessimism that usually occurs when a simulator
    is confronted with a lot of 'U' or 'X' values. This issue is
    one of those things that hardware designers are required
    to be aware of, and failure to attend to it is usually a good
    identifying mark of a beginner, or a dyed-in-the-wool
    programmer assuming that hardware design is easy.

    [..]"

    Regards,
    Colin Paul Gloster
     
    Colin Paul Gloster, Aug 28, 2007
    #15
  16. Weng Tianxiang

    Tricky Guest

    States A2 and A3 will function exactly the same, but A1 will be
    different. If you monitered State_A'transaction in a simulator you'd
    get a response on every clock cycle with A1, but only when A='1' for
    A2 and 3. It may mean the difference between synthesizing a register
    with an enable (in the case of A2 and A3) and without (A1).

    the null statement can be very useful for specifically ignoring
    certain cases.
     
    Tricky, Aug 28, 2007
    #16
  17. On 28 Aug., 16:09, Colin Paul Gloster <>
    wrote:
    >
    > Perhaps because they are too lazy to implement features which
    > customers can easily be led to believe are frills?

    I would say that they do not question decisions that were made by
    synopsys 20 years ago.

    > E.g. Jonathan
    > Bromley posted on 2007 March 5th:

    Hmm. I just have to counter that post here.

    > [..] The majority of
    > hardware platforms do not offer reliable power-up
    > initialisation of internal state.

    True. But the vast majority of design starts are on platforms that do
    support it.

    > Consequently it is appropriate
    > to code explicitly some reset behaviour.

    At extra hardware cost on my platform.

    > For exactly this
    > reason, the hardware-oriented data types in VHDL (std_logic,
    > etc) have a specific undefined value as the leftmost value
    > of their value-set, so that initialisation oversights are
    > more likely to be detected.


    So, when I explicitly assign an initial value of '1' and then start
    synthesis for a platform that supports initial values the synthesis
    tool
    should synthesize to an initial value of '0'? How does that detect
    initialization oversight?
    It is an implementation error. Plain and simple.

    Leaving the initial value unassigned makes formal verification a PITA.

    > This issue is
    > one of those things that hardware designers are required
    > to be aware of,

    Surely the OP meant "ASIC designres".

    > and failure to attend to it is usually a good
    > identifying mark of a beginner, or a dyed-in-the-wool
    > programmer assuming that hardware design is easy.


    Well it isn't. But it could if tools would catch up. We spend easily
    25% of the design time
    of the last project debugging the tools.
    (Deciphering such great synthesis guidelines as the statement that
    arrays should not be used.
    Instead std_logic_vector should be used. But that is an array. Hmm.)

    Kolja Sulimma
     
    comp.arch.fpga, Aug 28, 2007
    #17
  18. Weng Tianxiang

    Jim Lewis Guest

    Andy and Mike,
    >> From Mike
    >> I get really frustrated when I try to implement something using
    >> standard VHDL and find that it is incorrectly or incompletely
    >> supported. I wish more people would have higher standards with the
    >> software they use. The way I see it, it's false advertising to
    >> advertise something as a VHDL synthesizer if it doesn't completely
    >> implement the VHDL standard, but not many seem to agree with me.
    >>
    >> I think it comes down to the difference between engineers and
    >> scientists. Scientists prefer theory, and deviations from the ideal
    >> grate on us. Engineers prefer practicality, and will tend to solder on
    >> (pun intended) through crappy software, more interested in the end
    >> result than the process. I have grounding in both, so I complain as I
    >> implement, and depend less on crappy software whenever the chance
    >> presents itself. Life's too short for bad software.


    I think the status-quo is more complex than you state.
    Vendors don't implement standards just because just because they
    have neat features. It is about marketing and investing. A vendor
    invests in features that will make them money and/or differentiate
    their software from a competitors.

    If you want change, you need to focus on communicating to them what
    features you require. They listen best to the people with $$$, so
    you may wish to file bug reports with both your vendor and with the
    person paying for the tools (or at least let the person paying for
    tools know about open bugs on a regular basis). Short of this,
    we would all have to pool together and talk to them collectively.


    > from Andy
    > There is an ieee standard for the "minimum" synthesizable subset of
    > vhdl, but its creation was dominated by the big player(s) in
    > synthesis, and focused on what they had already implemented.

    Actually most big players did not participate. At the time there
    were concerns with loosing patents due to standards participation.

    The theory behind the minimum was so a IP supplier would have a
    standard to claim compliance to. The second standard actually was
    started as soon as the first one was done, so I still believe it
    was the best decision.


    > Since then, updates to the standard have been few and far between,

    The first revision was 1076.6-1999 and 1076.6-2004.
    While that is slow, standards are a volunteer effort.
    You get what you invest. We need more user companies
    who are interested in this to invest the time.

    > and the standard has also migrated from a template based approach,
    > to a behavioral approach.

    An idea put forward by tool vendors. At the time it seemed to be
    a good way to avoid having a huge set of templates and leaving a
    few critical ones behind.

    At this point, the standard is due for revision by 2009.
    Since vendors have not implemented all of it, it would be
    an opportune time to change the approach if it is appropriate
    to do so. Myself, I am tied up with the general language revision,
    however, it is a good "starter" place for participating in standards.
    Particularly for experienced designers who regularly voice an
    opinion here (like Andy J, Mike T, Jon B, KJ, ... not meaning to leave
    any interested party out).

    Quit bitching, get the vendors involved and make it a standard
    you can live with and a standard the vendors will implement.

    Cheers,
    Jim
     
    Jim Lewis, Aug 28, 2007
    #18
  19. Weng Tianxiang

    Andy Guest

    On Aug 28, 9:11 am, Tricky <> wrote:
    > States A2 and A3 will function exactly the same, but A1 will be
    > different. If you monitered State_A'transaction in a simulator you'd
    > get a response on every clock cycle with A1, but only when A='1' for
    > A2 and 3. It may mean the difference between synthesizing a register
    > with an enable (in the case of A2 and A3) and without (A1).
    >
    > the null statement can be very useful for specifically ignoring
    > certain cases.


    I agree, the null statement is usually built-in documentation that
    says either "I haven't gotten that far yet" or "Yes I did consider
    this, and am not doing anything here". Sometimes (i.e. case
    statements) it is necessary for completeness.

    Andy
     
    Andy, Aug 28, 2007
    #19
  20. On Tue, 28 Aug 2007 14:26:59 -0000, "comp.arch.fpga"
    <> wrote:


    >> E.g. Jonathan Bromley posted on 2007 March 5th:

    >Hmm. I just have to counter that post here.
    >
    >> [..] The majority of
    >> hardware platforms do not offer reliable power-up
    >> initialisation of internal state.

    >True. But the vast majority of design starts are on platforms that do
    >support it.


    I have spoken with forked tongue....

    You may recall that a while ago I had a dispute about this
    with Rob Dekker of Verific (a software company whose prime
    product is an HDL front-end, used by many vendors of synthesis,
    formal and linting tools): see the thread

    Coding style, wait statement, sensitivity list and synthesis.

    in comp.lang.vhdl around January 2006. I tried there to
    argue that synthesis front-ends should support any construct
    that maps to physically realisable hardware, and the back-end
    (mapper) should error-out if the specific target does not
    support the necessary features. I still think I was right,
    but I don't think my arguments prevailed. So I have reverted
    to my standard, conservative position that synthesis users
    should restrict themselves to a lowest-common-denominator
    style. I make a few exceptions: for example, there are
    still synthesis tools around (at least, there were the
    last time I checked) that won't tolerate Verilog
    with a mixture of blocking and nonblocking assignments,
    thereby making it impossible to emulate VHDL variables
    in Verilog. That is so laughably stupid that I'm prepared
    to tell people not to use such tools. But support for
    initialization is still restricted to a small subset
    of the available tools, so I can't reasonably recommend
    it except to Xilinx- or Altera-specific users.

    My conservative position must not be taken as an argument
    that we shouldn't try to move forward. Basically I agree
    with everything Kolja has said; it's just that I am obliged
    to help people to make the best of what they have today -
    and sometimes those people need to write highly portable code.
    --
    Jonathan Bromley, Consultant

    DOULOS - Developing Design Know-how
    VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

    Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, Sep 2, 2007
    #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. Kelvin
    Replies:
    1
    Views:
    3,216
    Kelvin
    Sep 13, 2003
  2. walala
    Replies:
    2
    Views:
    682
    Ken Smith
    Oct 11, 2003
  3. Mike Treseler
    Replies:
    0
    Views:
    544
    Mike Treseler
    Sep 12, 2003
  4. Jim Lewis
    Replies:
    1
    Views:
    536
    walala
    Sep 16, 2003
  5. Replies:
    5
    Views:
    26,962
    Mike Schilling
    Mar 29, 2006
Loading...

Share This Page