inside or outside of the case statement ?

Discussion in 'VHDL' started by Calvin T, Nov 20, 2009.

  1. Calvin T

    Calvin T Guest

    Hi all,

    I hope you folks can help settle a debate regarding statement position
    from a legacy design.

    My coworker thinks position of 2 statements right after the big ELSE
    statement is okay as if.

    I think such position makes these 2 staments concurrent to the case
    statement and may cause unexpected result.

    These 2 statements should be moved inside the case statement as shown
    below and one statement, e_reset_b <= '1' ; added in event_mux state
    if the intention is to keep e_reset_b signal staying HI at the end.

    While simulations currently show the same result in both cases, which
    approach is correct or more reliable ?

    Thanks,

    Calvin

    =================================================================

    process (clk, nreset)
    begin
    if nreset = '0' THEN
    er_state <= idle;
    e_reset_b <= '1' ;
    e_mux <= '0' ;
    elsif rising_edge( clk) then
    IF nlfm = '0' THEN
    er_state <= idle;
    e_reset_b <= '1' ;
    e_mux <= '0' ;
    ELSE
    e_reset_b <= '1' ; -- <---------------- should NOT be
    here
    e_mux <= '0' ; -- <---------------- should NOT
    be here
    case er_state is
    when idle =>
    e_reset_b <= '1' ; -- <---------------- should be here
    e_mux <= '0' ; -- <---------------- should
    be here
    if event_reset = '1' then
    er_state <= event_rst ;
    end if;
    when event_rst =>
    if event_reset = '0' then
    er_state <= event_mux ;
    end if;
    e_reset_b <= '0' ;
    when event_mux =>
    e_reset_b <= '1' ; -- Added to stay HI at the end
    e_mux <= '1' ;
    when others =>
    er_state <= event_mux;
    e_reset_b <= '1' ;
    e_mux <= '1' ;
    end case;
    END IF;
    end if;
    end process;
    Calvin T, Nov 20, 2009
    #1
    1. Advertising

  2. Calvin T

    jens Guest

    Your coworker is correct - it's OK and there are no unexpected
    results. I would take that concept one step further and assign
    default values outside of the if statement and only assign non-default
    values when necessary, as it makes it much easier to read, understand
    and maintain. Something like this:

    process (clk, nreset)
    begin
    if nreset = '0' THEN
    er_state <= idle;
    e_reset_b <= '1' ;
    e_mux <= '0' ;
    elsif rising_edge( clk) then

    -- default values
    e_reset_b <= '1' ;
    e_mux <= '0' ;

    IF nlfm = '0' THEN
    er_state <= idle;
    ELSE
    case er_state is
    when idle =>
    if event_reset = '1' then
    er_state <= event_rst ;
    end if;
    when event_rst =>
    if event_reset = '0' then
    er_state <= event_mux ;
    end if;
    e_reset_b <= '0' ;
    when event_mux =>
    e_mux <= '1' ;
    when others =>
    er_state <= event_mux;
    e_mux <= '1' ;
    end case;
    END IF;
    end if;
    end process;
    jens, Nov 20, 2009
    #2
    1. Advertising

  3. Calvin T wrote:

    > process (clk, nreset)
    > begin
    > if nreset = '0' THEN
    > er_state <= idle;
    > e_reset_b <= '1' ;
    > e_mux <= '0' ;
    > elsif rising_edge( clk) then
    > IF nlfm = '0' THEN
    > er_state <= idle;
    > e_reset_b <= '1' ;
    > e_mux <= '0' ;
    > ELSE
    > e_reset_b <= '1' ; -- <--------- should NOT behere
    > e_mux <= '0' ; -- <--------- should NOT be here
    > case er_state is
    > when idle =>
    > e_reset_b <= '1' ; -- <---- should be here
    > e_mux <= '0' ; -- <---- should be here
    > if event_reset = '1' then
    > er_state <= event_rst ;
    > end if;
    > when event_rst =>
    > if event_reset = '0' then
    > er_state <= event_mux ;
    > end if;
    > e_reset_b <= '0' ;
    > when event_mux =>
    > e_reset_b <= '1' ; -- Added to stay HI at the end
    > e_mux <= '1' ;
    > when others =>
    > er_state <= event_mux;
    > e_reset_b <= '1' ;
    > e_mux <= '1' ;
    > end case;
    > END IF;
    > end if;
    > end process;


    > While simulations currently show the same result in both cases, which
    > approach is correct or more reliable ?


    That ELSE clause can only happen at the end of reset
    so I expect that it isn't doing anything.
    I would take it out in any case.

    Since I don't know what e_reset_b does,
    you will have to decide if it should
    be driven by any idle state, or directly by nreset.


    -- Mike Treseler
    Mike Treseler, Nov 20, 2009
    #3
  4. Mike Treseler wrote:

    > That ELSE clause can only happen at the end of reset
    > so I expect that it isn't doing anything.


    Sorry, I misread the code. See Jens' posting.

    I should have said,
    "If your testbench can't see the difference,
    it is incomplete."
    Mike Treseler, Nov 20, 2009
    #4
  5. Calvin T

    Calvin T Guest

    On Nov 20, 11:10 am, Mike Treseler <> wrote:
    > Mike Treseler wrote:
    > > That ELSE clause can only happen at the end of reset
    > > so I expect that it isn't doing anything.

    >
    > Sorry, I misread the code. See Jens' posting.
    >
    > I should have said,
    > "If your testbench can't see the difference,
    > it is incomplete."



    Are these 2 statements and the CASE statement (as in the original
    version) or the IF statement (as Jens suggested) concurrent or
    sequential ?

    If all 3 are concurrent, can a signal, i.e. e_mux, get conflicting
    values at any specific time ?

    For example, when the state machine is in event_mux state, default
    sets e_mux to '0' and event_mux state sets e_mux to '1' ?

    Calvin
    Calvin T, Nov 20, 2009
    #5
  6. Calvin T

    Dave Guest

    On Nov 20, 3:26 pm, Calvin T <> wrote:
    > On Nov 20, 11:10 am, Mike Treseler <> wrote:
    >
    > > Mike Treseler wrote:
    > > > That ELSE clause can only happen at the end of reset
    > > > so I expect that it isn't doing anything.

    >
    > > Sorry, I misread the code. See Jens' posting.

    >
    > > I should have said,
    > > "If your testbench can't see the difference,
    > > it is incomplete."

    >
    > Are these 2 statements and the CASE statement (as in the original
    > version) or the IF statement (as Jens suggested) concurrent or
    > sequential ?
    >
    > If all 3 are concurrent, can a signal, i.e. e_mux, get conflicting
    > values at any specific time ?
    >
    > For example, when the state machine is in event_mux state, default
    > sets e_mux to '0' and event_mux state sets e_mux to '1' ?
    >
    > Calvin


    These statements are inside of a process, which makes them sequential
    by definition. Statements outside of a process are concurrent. Being
    inside or outside of a process is what distinguishes the sequential
    and concurrent statements in VHDL.

    Dave
    Dave, Nov 20, 2009
    #6
  7. Calvin T

    Calvin C Guest

    Hi Jens,

    Another coworker of mine and I talked about your suggestion today.

    He strongly believed that having different assignment statements to
    the same signal both inside and outside of an "if" statement may
    confuse the synthesis tool (i.e. Synopsys or Synplicity) since all
    assigned values to the same FF must be evaluated within one clock
    cycle.

    Despite of the fact that the statements are sequential, the synthesis
    result is unpredictable; the netlist may end up with an incorrect
    implementation!

    While I thought it should be okay, it seems I have nothing else to
    back me up.

    Is this a valid concern ?

    Thanks,

    Calvin

    On Nov 20, 10:37 am, jens <> wrote:
    > Your coworker is correct - it's OK and there are no unexpected
    > results.  I would take that concept one step further and assign
    > default values outside of the if statement and only assign non-default
    > values when necessary, as it makes it much easier to read, understand
    > and maintain.  Something like this:
    >
    > process (clk, nreset)
    > begin
    >     if nreset = '0' THEN
    >         er_state  <= idle;
    >         e_reset_b <= '1' ;
    >         e_mux <= '0' ;
    >     elsif rising_edge( clk) then
    >
    >         -- default values
    >         e_reset_b <= '1' ;
    >         e_mux <= '0' ;
    >
    >         IF nlfm = '0' THEN
    >             er_state  <= idle;
    >         ELSE
    >             case er_state is
    >                 when idle =>
    >                     if event_reset = '1' then
    >                         er_state <= event_rst ;
    >                     end if;
    >                 when event_rst =>
    >                     if event_reset = '0' then
    >                         er_state <= event_mux ;
    >                     end if;
    >                     e_reset_b <= '0' ;
    >                 when event_mux =>
    >                     e_mux <= '1' ;
    >                 when others =>
    >                     er_state  <= event_mux;
    >                     e_mux <= '1' ;
    >             end case;
    >         END IF;
    >     end if;
    > end process;
    Calvin C, Dec 17, 2009
    #7
  8. Calvin T

    joris

    Joined:
    Jan 29, 2009
    Messages:
    152
    As far as I know, the tool is really broken if it gets confused by such a construct;
    joris, Dec 18, 2009
    #8
  9. Calvin T

    KJ Guest

    On Dec 17, 6:33 pm, Calvin C <> wrote:
    > Hi Jens,
    >
    > Another coworker of mine and I talked about your suggestion today.
    >
    > He strongly believed that having different assignment statements to
    > the same signal both inside and outside of an "if" statement may
    > confuse the synthesis tool (i.e. Synopsys or Synplicity)


    Beliefs are totally irrelevant in this discussion. You and your
    coworker should spend a bit more time actually using the tools and
    testing these 'beliefs'.

    > since all assigned values to the same FF must be evaluated
    > within one clock cycle.
    >


    The synthesis tool does not 'evaluate all assigned values within one
    clock cycle'. You make it seem like if there were 100 assignments to
    the same signal that the synthesis tool would maybe get tired or run
    out of time before the next clock comes along or while trying to
    figure out what to set the signal to.

    That's not at all what synthesis does. What synthesis *does* do is
    compute the boolean logic equivalent of what you've written, sum of
    products, and gates, or gates, things like that. Once it can express
    a signal as a boolean function of 4-6 other signals, it can then map
    this boolean function to a lookup table memory device which can then
    implement whatever that boolean logic it happens to be...if that
    signal is inside a clocked process, it enables the flop in that logic
    block.

    If there are other hardware structures inside the target device that
    it can take advantage of, then it will instead stop at the point where
    it recognizes that structure in the code (i.e. when it sees y <= a *
    b; and it has hardware multiplier in the target device, it will map
    that signal to a multiplier rather than spell out the boolean logic to
    implement the multiplier...if it has no such multiplier hardware then
    yes it will compute the boolean logic)

    > Despite of the fact that the statements are sequential, the synthesis
    > result is unpredictable; the netlist may end up with an incorrect
    > implementation!
    >


    And you have proof of this rather strange assertion?

    Turning source code into boolean logic is not rocket science (although
    doing a good job of it and coming up with fast, compact logic is a bit
    tougher task).

    Every tool has bugs that have yet to be discovered and eradicated. If
    you were to actually come up with some source code that demonstrated
    your statement, you should file a bug report, find a temporary work
    around and get on with it but don't assume that this is somehow
    generally true of all synthesis tools. Try the same code with another
    tool and it probably works.

    The discovery of a bug is not proof that 'the synthesis result is
    unpredictable the netlist may end up with an incorrect
    implementation!' it is the discovery of a bug...that will get fixed in
    some future release. I've submitted dozens of these to the tool
    suppliers. Doing so improves the tool eventually for everyone.

    > While I thought it should be okay, it seems I have nothing else to
    > back me up.
    >


    Opinions are cheap, everyone has one. It seems that it hasn't
    occurred to you, that the only 'backup' you need is actual
    results...you'll get that by testing your ideas and your coworker's
    ideas on a real tool. It looks like you'll both be surprised at how
    well the tool really does.

    > Is this a valid concern ?
    >


    No, but don't take my word for it (see above regarding the value of
    opinions).

    Instead try doing some homework and you'll come away much better off
    than any good feelings you could get from a newsgroup. I suggest the
    following regimen:

    1. Write some code that you or your co-worker 'believe' would be
    troublesome for the synthesizer to handle that is legit for a
    synthesizable design (i.e. no delay lines, no transparent latches if
    the target device doesn't have hard latches, etc.)
    2. Synthesize it
    3. Create a testbench and simulate the original design
    4. Substitute the post route simulation model for your original design
    and re-run the testbench
    5. If your results differ, wrap it up as a test case and submit a bug
    report to the synthesis supplier.
    5a. Find a work around to the bug...you'll need it until the bug gets
    fixed. If you can't find a work around pressure the supplier to find
    one because you're stopped and won't use their part until you have a
    work around.
    6. If your results do match, go back to step 1. Do not exit this loop
    until you're satisfied that the generalizations that you and your
    coworker have are completely baseless.

    KJ
    KJ, Dec 18, 2009
    #9
  10. Calvin T

    Jan Decaluwe Guest

    Calvin C wrote:
    > Hi Jens,
    >
    > Another coworker of mine and I talked about your suggestion today.
    >
    > He strongly believed that having different assignment statements to
    > the same signal both inside and outside of an "if" statement may
    > confuse the synthesis tool (i.e. Synopsys or Synplicity) since all
    > assigned values to the same FF must be evaluated within one clock
    > cycle.


    A signal is not a FF. A FF may be inferred from signal behavior.

    > Despite of the fact that the statements are sequential, the synthesis
    > result is unpredictable; the netlist may end up with an incorrect
    > implementation!


    Not true.

    > While I thought it should be okay, it seems I have nothing else to
    > back me up.


    You have: you can easily do some small experiments where
    your coworker thinks it will go wrong, and you will see that
    it's always OK.

    > Is this a valid concern ?


    No. The confusion comes from a misunderstanding of VHDL semantics,
    and the capabilities of synthesis.


    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, Dec 18, 2009
    #10
  11. Calvin C wrote:

    > Despite of the fact that the statements are sequential, the synthesis
    > result is unpredictable; the netlist may end up with an incorrect
    > implementation!


    If I knew the expected netlist in advance,
    I wouldn't need synthesis at all.

    For the last 9 years, I have found that fpga synthesis netlists
    always sim the same as my code, unless there is a warning.

    > While I thought it should be okay, it seems I have nothing else to
    > back me up.


    I would consult the Oracle, Modelsim.

    The whole point of simulation is that
    I can see what my *code* does, with synthesis out of the loop.

    -- Mike Treseler
    Mike Treseler, Dec 18, 2009
    #11
  12. Calvin T

    Andy Guest

    I think I'd quit asking that co-worker for advice on synthesis.

    He/she does not have a clue.

    Andy
    Andy, Dec 18, 2009
    #12
  13. Calvin T

    prano2

    Joined:
    Dec 25, 2009
    Messages:
    1
    Hello everyone,
    I'm a newbie in vhdl. And i'm having a project to build a 5 stage pipelined risc 32-bit microprocessor.
    I have completed building all the modules that is alu, memory, register files etc. I'm having problem in how to implement pipelining concept.
    Plz can any one guide me in coding the pipelining concept.
    Thanks in advance!
    prano2, Dec 25, 2009
    #13
    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. Steve Franks
    Replies:
    2
    Views:
    1,242
    Steve Franks
    Jun 10, 2004
  2. Alexander Korsunsky

    break inside of case- statement inside of loop

    Alexander Korsunsky, Feb 25, 2007, in forum: C Programming
    Replies:
    25
    Views:
    1,052
    Richard Heathfield
    Feb 27, 2007
  3. aa
    Replies:
    14
    Views:
    315
  4. Paul Smith
    Replies:
    8
    Views:
    197
    Alex Gutteridge
    Jan 11, 2007
  5. Krzysztof Poc

    outside type, outside function

    Krzysztof Poc, Feb 3, 2012, in forum: C++
    Replies:
    1
    Views:
    275
    Victor Bazarov
    Feb 7, 2012
Loading...

Share This Page