Help: what does this VHDL code mean?

Discussion in 'VHDL' started by Pratip Mukherjee, Jun 22, 2005.

  1. process(clock) is
    begin
    if clock'event and clock = '1'
    then
    o <= '1';
    if (<some conditional>)
    then
    o <= '0';
    end if;
    end if;
    end process;

    My question is how to interpret this: is the value of o is first set to
    '1' and then set to '0' or is it that o is set to '0' or '1' depending on
    whether the condition is true. Is it a good VHDL coding style? If so, why
    don't I see a single example/explanation of it in Peter Ashendon's book?
    Thanks in advance.

    - Pratip.
    Pratip Mukherjee, Jun 22, 2005
    #1
    1. Advertising

  2. Pratip Mukherjee

    newsgroup Guest

    Re: what does this VHDL code mean?

    Hi Pratip,

    The code will infer a mux and a flip flop.
    For all cases in which <condition> is true output will be zero else one.

    There is nothing wrong in this coding style, except for readability and
    straightforwardness. It is equivalent to this code.
    process(clock) is
    begin
    if clock'event and clock = '1' then
    if (<some conditional>) then
    o <= '0';
    else
    o <= '1' ;
    end if;
    end if;
    end process;



    "Pratip Mukherjee" <> wrote in message
    news:...
    > process(clock) is
    > begin
    > if clock'event and clock = '1'
    > then
    > o <= '1';
    > if (<some conditional>)
    > then
    > o <= '0';
    > end if;
    > end if;
    > end process;
    >
    > My question is how to interpret this: is the value of o is first set to
    > '1' and then set to '0' or is it that o is set to '0' or '1' depending on
    > whether the condition is true. Is it a good VHDL coding style? If so, why
    > don't I see a single example/explanation of it in Peter Ashendon's book?
    > Thanks in advance.
    >
    > - Pratip.
    newsgroup, Jun 22, 2005
    #2
    1. Advertising

  3. Pratip Mukherjee

    Neo Guest

    Re: what does this VHDL code mean?

    More probably it will infer an NOT of condition to the 'd' input of
    the FF.
    Neo, Jun 22, 2005
    #3
  4. Pratip Mukherjee

    Klaus Falser Guest

    In article <>,
    says...
    > process(clock) is
    > begin
    > if clock'event and clock = '1'
    > then
    > o <= '1';
    > if (<some conditional>)
    > then
    > o <= '0';
    > end if;
    > end if;
    > end process;
    >
    > My question is how to interpret this: is the value of o is first set to
    > '1' and then set to '0' or is it that o is set to '0' or '1' depending on
    > whether the condition is true. Is it a good VHDL coding style? If so, why
    > don't I see a single example/explanation of it in Peter Ashendon's book?
    > Thanks in advance.
    >
    > - Pratip.
    >


    This coding style is less useful together with an if statement,
    but very useful in conjunction with a case statement
    (when programming FSM's).

    It allows you to assign a default value and set your output
    signal only under certain conditions.

    In the following example you have a output_enable signal
    which must always be '0', exept when writing.

    process(clock) is
    begin
    if rising_edge(clock) then
    output_enable <= '0';
    case (state) is
    when idle =>
    <do nothing, output_enable remains at '0'>
    when writing =>
    output_enable <= '1';
    when reading =>
    <something else, output_enable remains at '0'>
    when someOtherState =>
    <something else too, output_enable remains at '0'>
    end case;
    end if;
    end process;

    Without this style you had to assign a value for "output_enable"
    in all states, blowing up your code.

    The signal output_enable itself is NOT set first to '0' and
    then to '1' when then when writing, but is set cleanly to '0'
    or '1'.

    Remember, in VHDL the new values for the signals are assigned
    only at the end of the simulation cycle.
    During the calculation of the new value for the signal there is an
    intermediate result of '0', evenually replaced by '1' when we are
    in the writing state, but the signal itself gets only the RESULT of
    the calculus.

    Best regards
    Klaus Falser
    Klaus Falser, Jun 22, 2005
    #4
  5. Pratip Mukherjee

    fred Guest

    In article <>, Klaus Falser
    <> writes
    >In article <>,
    >says...
    >> process(clock) is
    >> begin
    >> if clock'event and clock = '1'
    >> then
    >> o <= '1';
    >> if (<some conditional>)
    >> then
    >> o <= '0';
    >> end if;
    >> end if;
    >> end process;
    >>
    >> My question is how to interpret this: is the value of o is first set to
    >> '1' and then set to '0' or is it that o is set to '0' or '1' depending on
    >> whether the condition is true. Is it a good VHDL coding style? If so, why
    >> don't I see a single example/explanation of it in Peter Ashendon's book?

    Maybe he doesn't think it is a good way to code, I would agree with him.
    >
    >This coding style is less useful together with an if statement,
    >but very useful in conjunction with a case statement
    >(when programming FSM's).

    IMO, dirty programming

    >It allows you to assign a default value and set your output
    >signal only under certain conditions.
    >
    >In the following example you have a output_enable signal
    >which must always be '0', exept when writing.
    >
    >process(clock) is
    >begin
    > if rising_edge(clock) then
    > output_enable <= '0';
    > case (state) is
    > when idle =>
    > <do nothing, output_enable remains at '0'>
    > when writing =>
    > output_enable <= '1';
    > when reading =>
    > <something else, output_enable remains at '0'>
    > when someOtherState =>
    > <something else too, output_enable remains at '0'>
    > end case;
    > end if;
    >end process;
    >
    >Without this style you had to assign a value for "output_enable"
    >in all states, blowing up your code.

    Any reason for not covering this with:
    when (others) =>
    output_enable <= '0';
    which I think is a far cleaner.

    >Remember, in VHDL the new values for the signals are assigned
    >only at the end of the simulation cycle.
    >During the calculation of the new value for the signal there is an
    >intermediate result of '0', evenually replaced by '1' when we are
    >in the writing state, but the signal itself gets only the RESULT of
    >the calculus.

    But life (hardware) isn't a simulation, I'd rather write something that follows
    the way hardware will actually perform (albeit at a high level) than make
    use techniques like those above.
    --
    fred
    fred, Jun 22, 2005
    #5
  6. fred wrote:

    >>Without this style you had to assign a value for "output_enable"
    >>in all states, blowing up your code.

    >
    > Any reason for not covering this with:
    > when (others) =>
    > output_enable <= '0';
    > which I think is a far cleaner.


    That is different code at functional level, it should create latches.
    In VHDL the case statements are mutually exclusive (1076-1993 8.8 Note 1).
    So in your code the output_enable value comes from the previous round in
    the undefined cases.

    Setting the default value at the beginning and changing it inside
    the case clauses makes the code easier to read in very complex state
    machines. It's easier to see, what values are important. Also in very
    deep if-clauses that style usually cuts down the needed else branches.


    >>Remember, in VHDL the new values for the signals are assigned
    >>only at the end of the simulation cycle.

    >
    > But life (hardware) isn't a simulation, I'd rather write something that follows
    > the way hardware will actually perform (albeit at a high level) than make
    > use techniques like those above.


    Simulation follows hardware, if synthesis subset of the language is used.
    Setting default value is normal way of doing this for synthesizable code.

    --Kim
    Kim Enkovaara, Jun 22, 2005
    #6
  7. Pratip Mukherjee

    fred Guest

    In article <whcue.8035$7%>, Kim
    Enkovaara <> writes
    >fred wrote:
    >
    >>>Without this style you had to assign a value for "output_enable"
    >>>in all states, blowing up your code.

    >>
    >> Any reason for not covering this with:
    >> when (others) =>
    >> output_enable <= '0';
    >> which I think is a far cleaner.

    >
    >That is different code at functional level, it should create latches.

    I disagree, a case is a decoder, the others term (the brackets were a
    mistake btw) just fills in the empty slots, I see no latches.

    >In VHDL the case statements are mutually exclusive (1076-1993 8.8 Note 1).
    >So in your code the output_enable value comes from the previous round in
    >the undefined cases.

    Nope

    >Setting the default value at the beginning and changing it inside
    >the case clauses makes the code easier to read in very complex state
    >machines. It's easier to see, what values are important. Also in very
    >deep if-clauses that style usually cuts down the needed else branches.

    From a real world hardware perspective I look upon this sort of thing as
    multiple sources (even though in VHDL it is not) and so won't do it;
    irrespective of whether tools 'know what I mean'.

    >>>Remember, in VHDL the new values for the signals are assigned
    >>>only at the end of the simulation cycle.

    >>
    >> But life (hardware) isn't a simulation, I'd rather write something that follows
    >> the way hardware will actually perform (albeit at a high level) than make
    >> use techniques like those above.

    >
    >Simulation follows hardware, if synthesis subset of the language is used.
    >Setting default value is normal way of doing this for synthesizable code.

    In hardware, the signal does not set to one level and then change to
    another one (or how ever many) deltas later so in that way simulation does
    not follow hardware.
    --
    fred
    fred, Jun 22, 2005
    #7
  8. Pratip Mukherjee

    Klaus Falser Guest

    In article <>, says...
    > In article <>, Klaus Falser
    > <> writes
    > ...
    > >Remember, in VHDL the new values for the signals are assigned
    > >only at the end of the simulation cycle.
    > >During the calculation of the new value for the signal there is an
    > >intermediate result of '0', evenually replaced by '1' when we are
    > >in the writing state, but the signal itself gets only the RESULT of
    > >the calculus.

    > But life (hardware) isn't a simulation, I'd rather write something that
    > follows the way hardware will actually perform (albeit at a high level)
    > than make use techniques like those above.
    >


    This has nothing to do with simulation vs. hardware but is the way VHDL
    works.
    VHDL is simply NOT a programming language, an assignment to a signal in
    VHDL is something completely different from an assigning of a value to a
    variable (they exist in VHDL too !).
    Be assured, if written this way the hardware will do exactly the same as
    the code says.

    Best regards
    Klaus Falser
    Klaus Falser, Jun 22, 2005
    #8
  9. Pratip Mukherjee

    fred Guest

    In article <>, Klaus Falser
    <> writes
    >In article <>, says...
    >> In article <>, Klaus Falser
    >> <> writes
    >> ...
    >> >Remember, in VHDL the new values for the signals are assigned
    >> >only at the end of the simulation cycle.
    >> >During the calculation of the new value for the signal there is an
    >> >intermediate result of '0', evenually replaced by '1' when we are
    >> >in the writing state, but the signal itself gets only the RESULT of
    >> >the calculus.

    >> But life (hardware) isn't a simulation, I'd rather write something that
    >> follows the way hardware will actually perform (albeit at a high level)
    >> than make use techniques like those above.
    >>

    >
    >This has nothing to do with simulation vs. hardware but is the way VHDL
    >works.
    >VHDL is simply NOT a programming language, an assignment to a signal in
    >VHDL is something completely different from an assigning of a value to a
    >variable (they exist in VHDL too !).

    Yes, I know :)

    >Be assured, if written this way the hardware will do exactly the same as
    >the code says.

    I didn't say it wouldn't, I said that I thought it was dirty programming and
    that I don't write my code that way, you do not have to agree with that.

    --
    fred
    fred, Jun 22, 2005
    #9
  10. Pratip Mukherjee

    Ben Jones Guest

    > VHDL is simply NOT a programming language

    I respectfully disagree. Rather:

    VHDL is not SIMPLY a programming language.

    -Ben-
    Ben Jones, Jun 22, 2005
    #10
  11. Pratip Mukherjee

    Klaus Falser Guest

    In article <y$>, says...
    > In article <whcue.8035$7%>, Kim
    > Enkovaara <> writes
    > >fred wrote:
    > >
    > >>>Without this style you had to assign a value for "output_enable"
    > >>>in all states, blowing up your code.
    > >>
    > >> Any reason for not covering this with:
    > >> when (others) =>
    > >> output_enable <= '0';
    > >> which I think is a far cleaner.

    > >
    > >That is different code at functional level, it should create latches.

    > I disagree, a case is a decoder, the others term (the brackets were a
    > mistake btw) just fills in the empty slots, I see no latches.
    >
    > >In VHDL the case statements are mutually exclusive (1076-1993 8.8 Note 1).
    > >So in your code the output_enable value comes from the previous round in
    > >the undefined cases.

    > Nope
    >
    > >Setting the default value at the beginning and changing it inside
    > >the case clauses makes the code easier to read in very complex state
    > >machines. It's easier to see, what values are important. Also in very
    > >deep if-clauses that style usually cuts down the needed else branches.

    > From a real world hardware perspective I look upon this sort of thing as
    > multiple sources (even though in VHDL it is not) and so won't do it;
    > irrespective of whether tools 'know what I mean'.
    >
    > >>>Remember, in VHDL the new values for the signals are assigned
    > >>>only at the end of the simulation cycle.
    > >>
    > >> But life (hardware) isn't a simulation, I'd rather write something that
    > >> follows
    > >> the way hardware will actually perform (albeit at a high level) than make
    > >> use techniques like those above.

    > >
    > >Simulation follows hardware, if synthesis subset of the language is used.
    > >Setting default value is normal way of doing this for synthesizable code.

    > In hardware, the signal does not set to one level and then change to
    > another one (or how ever many) deltas later so in that way simulation does
    > not follow hardware.
    >


    Hello Fred,
    apart from the rest which is wrong too, you really have to take a book
    and read how the VHDL simulator works.
    The delta cycles you mention in your answer are something completely
    different.
    When writing a VHDL code like the following

    process (clk) is
    begin
    o <= '0';
    if (condition) then
    o <= '1';
    end if;
    end process;

    it does not mean that o gets a value of '0' and some time later it gets
    a value of '1'.
    The statements between the "begin" and the "end process" are SEQUENTIAL
    STATEMENTS, which are executed at the same delta cycle and their purpose
    is to calculate eventual new values for the driven signals (o in this
    example).
    When the elaboration reaches the "end process" statement the simulator
    has found a new value for o, but only after ALL processes are elaborated
    this way the new values are really dumped to the signals (if the new
    value is different to the old one) and the signals effectively changed.
    There is not spike in the simulated signal !

    As I wrote it the other posting (I wrote it before I read this your
    posting), VHDL is not a programming language !
    Klaus Falser, Jun 22, 2005
    #11
  12. Pratip Mukherjee

    fred Guest

    In article <>, Klaus Falser
    <> writes
    >Hello Fred,
    >apart from the rest which is wrong too, you really have to take a book
    >and read how the VHDL simulator works.

    Believe it or not, I do know, I'm just crap at describing the reasons why I
    think this is a bad style.

    >As I wrote it the other posting (I wrote it before I read this your
    >posting), VHDL is not a programming language !

    I think that was the point I was trying to make (badly).

    Simply put I do not like this coding style so lets just leave it at that shall
    we?
    --
    fred
    fred, Jun 22, 2005
    #12
  13. Pratip Mukherjee

    jtw Guest

    "fred" <> wrote in message news:V$...
    > In article <>, Klaus Falser
    > <> writes
    >>In article <>, says...
    >>> In article <>, Klaus Falser
    >>> <> writes
    >>> ...
    >>> >Remember, in VHDL the new values for the signals are assigned
    >>> >only at the end of the simulation cycle.
    >>> >During the calculation of the new value for the signal there is an
    >>> >intermediate result of '0', evenually replaced by '1' when we are
    >>> >in the writing state, but the signal itself gets only the RESULT of
    >>> >the calculus.
    >>> But life (hardware) isn't a simulation, I'd rather write something that
    >>> follows the way hardware will actually perform (albeit at a high level)
    >>> than make use techniques like those above.
    >>>

    >>
    >>This has nothing to do with simulation vs. hardware but is the way VHDL
    >>works.
    >>VHDL is simply NOT a programming language, an assignment to a signal in
    >>VHDL is something completely different from an assigning of a value to a
    >>variable (they exist in VHDL too !).

    > Yes, I know :)
    >
    >>Be assured, if written this way the hardware will do exactly the same as
    >>the code says.

    > I didn't say it wouldn't, I said that I thought it was dirty programming
    > and
    > that I don't write my code that way, you do not have to agree with that.
    >
    > --
    > fred

    Once upon a time, I didn't write code that way. I didn't even realize that
    this was a valid way of writing code. Then, I had to take over someone
    else's code, and that person had written quite a bit this way. After my
    initial confusion, I realized that this is a simple (and perhaps elegant)
    way of managing the defaults. The value of writing this varies from case to
    case (not trying to be punny.)

    I often try to write code this way, rather than handling that last 'else'.
    But it's real value is, as someone mentioned, in complex state machines.
    Someone mentioned creating latches; for this process clocked on an edge, it
    won't create latches. And making an explicit 'others' description
    superfluous is a small benefit. But for trying to quickly identify which
    state and which conditions cause a change on a signal... priceless. (Just
    kidding. But there are definitely times where this, more succint style, can
    add to the readability.)

    Jason
    jtw, Jun 23, 2005
    #13
  14. fred wrote:

    > In article <whcue.8035$7%>, Kim
    > Enkovaara <> writes
    >
    >>fred wrote:
    >>
    >>
    >>>Any reason for not covering this with:
    >>>when (others) =>
    >>> output_enable <= '0';
    >>>which I think is a far cleaner.

    >>
    >>That is different code at functional level, it should create latches.

    >
    > I disagree, a case is a decoder, the others term (the brackets were a
    > mistake btw) just fills in the empty slots, I see no latches.
    >
    >
    >>In VHDL the case statements are mutually exclusive (1076-1993 8.8 Note 1).
    >>So in your code the output_enable value comes from the previous round in
    >>the undefined cases.

    >
    > Nope


    I think this is misunderstanding. I tought that you were trying to code the
    code like this:

    process(clock) is
    begin
    if rising_edge(clock) then
    case (state) is
    when idle => ...
    when writing =>
    output_enable <= '1';
    when reading => ...
    when someOtherState => ...
    when others =>
    output_enable <= '0';
    end case;
    end if;
    end process;

    And you tought:

    process(clock) is
    begin
    if rising_edge(clock) then
    case (state) is
    when writing =>
    output_enable <= '1';
    when others =>
    output_enable <= '0';
    end case;
    end if;
    end process;

    The example is little too simple, because usually there is a huge pile of
    signals inside the states. And then the others option is quite difficult
    to use. But the default value option is easy to use.


    > From a real world hardware perspective I look upon this sort of thing as
    > multiple sources (even though in VHDL it is not) and so won't do it;
    > irrespective of whether tools 'know what I mean'.


    Usually there are multiple sources to the combinatorial network. And the
    style does not imply multiple drivers to same signal. The tools
    know what you mean, because they must do that by definition (check how signal
    assignment and delta cycle is defined).

    And that default value style is used by designers very frequently. Usually
    by the more experienced designers. I sit on top of hunders of thousands
    of lines of VHDL code, made by a legion of VHDL coders. It's fun to check
    sometimes how different styles coders have, but also there are some
    commonalities. There are some styles that are dangerous in terms
    of the whole tool flow, but this is not one of them.


    >>Simulation follows hardware, if synthesis subset of the language is used.
    >>Setting default value is normal way of doing this for synthesizable code.

    >
    > In hardware, the signal does not set to one level and then change to
    > another one (or how ever many) deltas later so in that way simulation does
    > not follow hardware.


    In real HW the signal value can jump around during it's propagation
    trough the combinatorial logic, so it is not stable. It just has to
    be stable around the clock edge to fullfill the setup and hold times.
    That makes debugging of huge netlist quite painful, especially if the valid
    window is small due to tight timing.


    --Kim
    Kim Enkovaara, Jun 23, 2005
    #14
  15. Pratip Mukherjee

    fred Guest

    In article <OVoue.1320$>, jtw
    <> writes
    >Once upon a time, I didn't write code that way. I didn't even realize that
    >this was a valid way of writing code. Then, I had to take over someone
    >else's code, and that person had written quite a bit this way. After my
    >initial confusion, I realized that this is a simple (and perhaps elegant)
    >way of managing the defaults. The value of writing this varies from case to
    >case (not trying to be punny.)
    >
    >I often try to write code this way, rather than handling that last 'else'.
    >But it's real value is, as someone mentioned, in complex state machines.
    >Someone mentioned creating latches; for this process clocked on an edge, it
    >won't create latches. And making an explicit 'others' description
    >superfluous is a small benefit. But for trying to quickly identify which
    >state and which conditions cause a change on a signal... priceless. (Just
    >kidding. But there are definitely times where this, more succint style, can
    >add to the readability.)
    >
    >Jason
    >

    I've yet to see the light but will try to keep an open mind :)
    --
    fred
    fred, Jun 23, 2005
    #15
  16. Kim Enkovaara wrote:

    > In real HW the signal value can jump around during it's propagation
    > trough the combinatorial logic, so it is not stable. It just has to
    > be stable around the clock edge to fullfill the setup and hold times.
    > That makes debugging of huge netlist quite painful, especially if the valid
    > window is small due to tight timing.


    True, but static timing can find the paths.

    -- Mike Treseler
    Mike Treseler, Jun 23, 2005
    #16
  17. Mike Treseler wrote:
    > Kim Enkovaara wrote:
    >
    >> In real HW the signal value can jump around during it's propagation
    >> trough the combinatorial logic, so it is not stable. It just has to
    >> be stable around the clock edge to fullfill the setup and hold times.
    >> That makes debugging of huge netlist quite painful, especially if the
    >> valid
    >> window is small due to tight timing.

    >
    >
    > True, but static timing can find the paths.


    Unless there are bugs in the simulation or STA models. That happens
    from time to time. And those are not fun to debug. In my opinion
    netlevel simulations are only useful to find STA setup errors and
    possible problems between two views of the timing model.

    --Kim
    Kim Enkovaara, Jun 27, 2005
    #17
    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. afd
    Replies:
    1
    Views:
    8,270
    Colin Paul Gloster
    Mar 23, 2007
  2. bigyellow
    Replies:
    5
    Views:
    2,637
    diogratia
    Jul 12, 2008
  3. Li Ma
    Replies:
    1
    Views:
    2,263
    Roedy Green
    Mar 9, 2009
  4. Rahul
    Replies:
    4
    Views:
    547
    Robert Kern
    Apr 7, 2009
  5. C Barrington-Leigh
    Replies:
    1
    Views:
    1,178
    Tim Leslie
    Sep 10, 2010
Loading...

Share This Page