When is it to generate transparent latch or usual combinationallogic?

Discussion in 'VHDL' started by Weng Tianxiang, May 25, 2009.

  1. Hi,
    Through discussions of last problem title "Are all these claims in
    VHDL correct?" I understand how to recognize a transparent latch from
    a register.

    Here I gave an example to show what I am puzzled.

    State1_A : process(CLK)
    begin
    if CLK'event and CLK = '1' then
    if SINI = '1' then
    State1 <= Idle_S;
    else
    State1 <= State1_NS;
    end if;
    end if;
    end if;

    State1_B : process(State1, A1, A2)
    begin
    case State1 is
    when Idle_S =>
    if A1 = '1' then
    State1_NS <= X_S;
    else
    State1_NS <= Idle_S;
    end if;

    when X_S =>
    if A2 = '1' then
    State1_NS <= Idle_S;
    else
    State1_NS <= X_S;
    end if;
    end case;
    end process;

    State2_A : process(SINI, CLK)
    begin
    if CLK'event and CLK = '1' then
    if SINI = '1' then
    State2 <= Idle_S;
    else
    State2 <= State2_NS;
    end if;
    end if;
    end if;

    State2_B : process(State2, A1, A2)
    begin
    case State2 is
    when Idle_S =>
    if A1 = '1' then
    State2_NS <= X_S;
    -- else <-- key difference
    -- State2_NS <= Idle_S;
    end if;

    when X_S =>
    if A2 = '1' then
    State2_NS <= Idle_S;
    else
    State2_NS <= X_S;
    end if;
    end case;
    end process;

    From my experiences with state machine, VHDL compiler would generate
    warning for state2: "state machine state2 will be implemented as
    latches".

    Once It took me one week to have found the similar situation with the
    above state2 in my a long state machine.

    I don't know why VHDL compiler generate latches for state2.

    Thank you.

    Weng
     
    Weng Tianxiang, May 25, 2009
    #1
    1. Advertising

  2. Weng Tianxiang

    Dave Guest

    On May 25, 3:52 pm, Weng Tianxiang <> wrote:
    > Hi,
    > Through discussions of last problem title "Are all these claims in
    > VHDL correct?" I understand how to recognize a transparent latch from
    > a register.
    >
    > Here I gave an example to show what I am puzzled.
    >
    > State1_A : process(CLK)
    > begin
    >    if CLK'event and CLK = '1' then
    >       if SINI = '1' then
    >          State1 <= Idle_S;
    >       else
    >          State1 <= State1_NS;
    >       end if;
    >    end if;
    > end if;
    >
    > State1_B : process(State1, A1, A2)
    > begin
    >    case State1 is
    >       when Idle_S =>
    >          if A1 = '1' then
    >             State1_NS <= X_S;
    >          else
    >             State1_NS <= Idle_S;
    >          end if;
    >
    >       when X_S =>
    >          if A2 = '1' then
    >             State1_NS <= Idle_S;
    >          else
    >             State1_NS <= X_S;
    >          end if;
    >    end case;
    > end process;
    >
    > State2_A : process(SINI, CLK)
    > begin
    >    if CLK'event and CLK = '1' then
    >       if SINI = '1' then
    >          State2 <= Idle_S;
    >       else
    >          State2 <= State2_NS;
    >       end if;
    >    end if;
    > end if;
    >
    > State2_B : process(State2, A1, A2)
    > begin
    >    case State2 is
    >       when Idle_S =>
    >          if A1 = '1' then
    >             State2_NS <= X_S;
    > --         else                     <-- key difference
    > --            State2_NS <= Idle_S;
    >          end if;
    >
    >       when X_S =>
    >          if A2 = '1' then
    >             State2_NS <= Idle_S;
    >          else
    >             State2_NS <= X_S;
    >          end if;
    >    end case;
    > end process;
    >
    > From my experiences with state machine, VHDL compiler would generate
    > warning for state2: "state machine state2 will be implemented as
    > latches".
    >
    > Once It took me one week to have found the similar situation with the
    > above state2 in my a long state machine.
    >
    > I don't know why VHDL compiler generate latches for state2.
    >
    > Thank you.
    >
    > Weng


    Are you sure the latch isn't being created for State2_NS? You may want
    to put a "when others =>" clause at the end of the case statement to
    make sure State2_NS gets assigned something en every case. A default
    assignment at the top of the process would give similar effects.

    Also, SINI doesn't need to be in the sensitivity list for the State2
    process, but it shouldn't hurt anything other than simulation time.

    Dave
     
    Dave, May 25, 2009
    #2
    1. Advertising

  3. Weng Tianxiang

    Andy Guest

    Weng,

    You've told the synthesizer that state2_ns (the combinatorial signal,
    not the register) has to remember its previous value under certain
    circumstances, so it generates a latch to remember the value.

    Your choices to avoid the latch include a) avoiding combinatorial
    processes, b) including a default assignment (perhaps from the output
    of the associated register) in combinatorial processes, or c) making
    sure every possible execution path through the process results in all
    driven signals being assigned a value (and not just to themselves).

    I always choose (a). If you just have to use a combinatorial process,
    then (b) is much easier to read/write/verify/review than is(c).

    Andy
     
    Andy, May 25, 2009
    #3
  4. On May 25, 2:28 pm, Andy <> wrote:
    > Weng,
    >
    > You've told the synthesizer that state2_ns (the combinatorial signal,
    > not the register) has to remember its previous value under certain
    > circumstances, so it generates a latch to remember the value.
    >
    > Your choices to avoid the latch include a) avoiding combinatorial
    > processes, b) including a default assignment (perhaps from the output
    > of the associated register) in combinatorial processes, or c) making
    > sure every possible execution path through the process results in all
    > driven signals being assigned a value (and not just to themselves).
    >
    > I always choose (a). If you just have to use a combinatorial process,
    > then (b) is much easier to read/write/verify/review than is(c).
    >
    > Andy


    Hi Andy,
    "You've told the synthesizer that state2_ns (the combinatorial signal,
    not the register) has to remember its previous value under certain
    circumstances, so it generates a latch to remember the value."

    You are right and I understand it. I am interested in your method a.
    Could you give me an example on how to use your method a. in the above
    situation.

    Thank you.

    Weng
     
    Weng Tianxiang, May 26, 2009
    #4
  5. Weng Tianxiang

    Andy Guest

    Here ya go...

    State2 : process(CLK)
    begin
    if rising_edge(CLK) then
    if SINI = '1' then
    State2 <= Idle_S;
    else
    case State2 is
    when Idle_S =>
    if A1 = '1' then
    State2 <= X_S;
    end if;
    when X_S =>
    if A2 = '1' then
    State2 <= Idle_S;
    end if;
    end case;
    end if; -- sini
    end if; -- clk
    end process;


    Unless you know that SINI is initially asserted (to initialize the
    state machine), you will need a reset for the state machine too.

    Andy
     
    Andy, May 26, 2009
    #5
  6. On May 26, 5:58 am, Andy <> wrote:
    > Here ya go...
    >
    > State2 : process(CLK)
    > begin
    >    if rising_edge(CLK) then
    >       if SINI = '1' then
    >         State2 <= Idle_S;
    >       else
    >         case State2 is
    >         when Idle_S =>
    >           if A1 = '1' then
    >             State2 <= X_S;
    >           end if;
    >         when X_S =>
    >           if A2 = '1' then
    >             State2 <= Idle_S;
    >           end if;
    >         end case;
    >       end if; -- sini
    >    end if; -- clk
    > end process;
    >
    > Unless you know that SINI is initially asserted (to initialize the
    > state machine), you will need a reset for the state machine too.
    >
    > Andy


    Hi Andy and Brian,
    1. Good point: use one process state machine.
    2. How do you handle turn-on signals in a state machine?
    State2_B : process(State2, A1, A2)
    begin
    Turn_On <= '0';
    case State2 is
    when Idle_S =>
    if A1 = '1' then
    Turn_On <= '1';
    State2_NS <= X_S;
    -- else <-- key difference
    -- State2_NS <= Idle_S;
    end if;


    when X_S =>
    if A2 = '1' then
    State2_NS <= Idle_S;
    else
    State2_NS <= X_S;
    end if;
    end case;
    end process;

    3. I don't like one process state machine writing type and Xilinx and
    Altera all recommend using 2 process method. I have a state machine
    that has 3000 lines and 30 turn-on signals.
    One process method is hard to handle my situation.

    4. I say VHDL synthesizer should be SMARTER to avoid generating
    transparent latch in the exact my situations:
    Locally State2_NS is described as transparent latches, but globally,
    they are only used in one statement: State2 <= State2_NS; or they are
    assigned to registers: State2 which is the case signal in the case
    process so that
    generating transparent latches for State2_NS is OVER-REACTING and
    State2_NS should be generated as a combinational logic !!!

    That is what I want to say and highlight !!!

    Global optimization rule for VHDL synthesizers: if a type signal (as
    State2_NS) is specified in a case process (case process is a process
    that contains only one case statement as State2_B shows) as a latch
    type, and it is only used to be assigned to the case signal in the
    case process, the latch signal can be reduced to combinational logic
    without any harm, because the case register keeps the data unchanged
    for the latch signal.

    Weng
     
    Weng Tianxiang, May 26, 2009
    #6
  7. Andy wrote:
    > Here ya go...
    >
    > State2 : process(CLK)
    > begin
    > if rising_edge(CLK) then
    > if SINI = '1' then
    > State2 <= Idle_S;
    > else
    > case State2 is
    > when Idle_S =>
    > if A1 = '1' then
    > State2 <= X_S;
    > end if;
    > when X_S =>
    > if A2 = '1' then
    > State2 <= Idle_S;
    > end if;
    > end case;
    > end if; -- sini
    > end if; -- clk
    > end process;


    Thanks for taking the time to post this simplified solution.

    This thread demonstrates the clarity provided by
    minimizing the number of processes in a design entity.
    More importantly, it shows the downside of
    using an asynchronous process for synthesis.

    -- Mike Treseler
     
    Mike Treseler, May 26, 2009
    #7
  8. Weng Tianxiang

    Andy Guest

    This example shows one way to handle outputs, but inserts a one clock
    delay on the output.

    State2 : process(CLK)
    begin
    if rising_edge(CLK) then
    turn_on <= '0';
    if SINI = '1' then
    State2 <= Idle_S;
    else
    case State2 is
    when Idle_S =>
    if A1 = '1' then
    turn_on <= '1';
    State2 <= X_S;
    end if;
    when X_S =>
    if A2 = '1' then
    State2 <= Idle_S;
    end if;
    end case;
    end if; -- sini
    end if; -- clk
    end process;

    If you want to avoid the delay, just assert the output when you
    transition into the states in which you want it on. I think it was
    Jonathan Bromley that demonstrated a method, using variables, to
    describe state machine outputs more easily in a single clocked
    process.

    It's not that hard to do, and you don't get latches, ever!

    If you really prefer dual-process state machines, there are proven,
    easy ways to avoid latches in them (like default "State <= State_NS"
    assignments). Quite frankly, I'd prefer the synthesis vendors work on
    other optimizations that are more important to quality of results,
    than avoiding inferring latches from poorly written RTL code.

    Andy
     
    Andy, May 26, 2009
    #8
  9. On May 26, 3:21 pm, Andy <> wrote:
    > This example shows one way to handle outputs, but inserts a one clock
    > delay on the output.
    >
    > State2 : process(CLK)
    > begin
    >    if rising_edge(CLK) then
    >       turn_on <= '0';
    >       if SINI = '1' then
    >         State2 <= Idle_S;
    >       else
    >         case State2 is
    >         when Idle_S =>
    >           if A1 = '1' then
    >             turn_on <= '1';
    >             State2 <= X_S;
    >           end if;
    >         when X_S =>
    >           if A2 = '1' then
    >             State2 <= Idle_S;
    >           end if;
    >         end case;
    >       end if; -- sini
    >    end if; -- clk
    > end process;
    >
    > If you want to avoid the delay, just assert the output when you
    > transition into the states in which you want it on. I think it was
    > Jonathan Bromley that demonstrated a method, using variables, to
    > describe state machine outputs more easily in a single clocked
    > process.
    >
    > It's not that hard to do, and you don't get latches, ever!
    >
    > If you really prefer dual-process state machines, there are proven,
    > easy ways to avoid latches in them (like default "State <= State_NS"
    > assignments). Quite frankly, I'd prefer the synthesis vendors work on
    > other optimizations that are more important to quality of results,
    > than avoiding inferring latches from poorly written RTL code.
    >
    > Andy


    Hi Andy,
    "If you really prefer dual-process state machines, there are proven,
    easy ways to avoid latches in them (like default "State <= State_NS"
    assignments)."

    Very good suggestions !!! I will follow it in all my designs starting
    today. Actually I give a default value at head of each of important
    states, not for full state machine.

    But your method of one process with turn-on signal delayed by 1 clock
    is not acceptable to me.

    That is the fatal fault of one process and the main reason for me to
    use dual-process method.

    One may like vegetables and others may like beef and pork. There is no
    need to compare between two methods, I know, it is a long crusade in
    VHDL industry.

    Weng
     
    Weng Tianxiang, May 27, 2009
    #9
  10. Weng Tianxiang

    Andy Guest

    On May 26, 7:22 pm, Weng Tianxiang <> wrote:
    > On May 26, 3:21 pm, Andy <> wrote:
    >
    >
    >
    >
    >
    > > This example shows one way to handle outputs, but inserts a one clock
    > > delay on the output.

    >
    > > State2 : process(CLK)
    > > begin
    > >    if rising_edge(CLK) then
    > >       turn_on <= '0';
    > >       if SINI = '1' then
    > >         State2 <= Idle_S;
    > >       else
    > >         case State2 is
    > >         when Idle_S =>
    > >           if A1 = '1' then
    > >             turn_on <= '1';
    > >             State2 <= X_S;
    > >           end if;
    > >         when X_S =>
    > >           if A2 = '1' then
    > >             State2 <= Idle_S;
    > >           end if;
    > >         end case;
    > >       end if; -- sini
    > >    end if; -- clk
    > > end process;

    >
    > > If you want to avoid the delay, just assert the output when you
    > > transition into the states in which you want it on. I think it was
    > > Jonathan Bromley that demonstrated a method, using variables, to
    > > describe state machine outputs more easily in a single clocked
    > > process.

    >
    > > It's not that hard to do, and you don't get latches, ever!

    >
    > > If you really prefer dual-process state machines, there are proven,
    > > easy ways to avoid latches in them (like default "State <= State_NS"
    > > assignments). Quite frankly, I'd prefer the synthesis vendors work on
    > > other optimizations that are more important to quality of results,
    > > than avoiding inferring latches from poorly written RTL code.

    >
    > > Andy

    >
    > Hi Andy,
    > "If you really prefer dual-process state machines, there are proven,
    > easy ways to avoid latches in them (like default "State <= State_NS"
    > assignments)."
    >
    > Very good suggestions !!! I will follow it in all my designs starting
    > today. Actually I give a default value at head of each of important
    > states, not for full state machine.
    >
    > But your method of one process with turn-on signal delayed by 1 clock
    > is not acceptable to me.
    >
    > That is the fatal fault of one process and the main reason for me to
    > use dual-process method.
    >
    > One may like vegetables and others may like beef and pork. There is no
    > need to compare between two methods, I know, it is a long crusade in
    > VHDL industry.
    >
    > Weng- Hide quoted text -
    >
    > - Show quoted text -


    I agree there are multiple valid ways to design a state machine, each
    with their trade-offs (e.g. latches vs output timing issues). I prefer
    to deal with the former, and gain the other benefits of single,
    clocked process descriptions, others (yourself included) may not.
    Single, clocked process descriptions also allow the flexibility of
    using VHDL variables for specifying both combinatorial and registered
    behavior in a compact, straight-forward manner (the circuit behaves
    just like the code sequential code reads).

    One of the primary benefits of assigning default values in
    combinatorial processes, right up front, for every signal driven by
    that process, is that this is the most easily remembered/verified/
    reviewed place to do it. You can default the state variable to the
    current registered value, but choose to default outputs either to the
    "off" state or to the current registered value, depending on how you
    want to describe the output in the state machine. For example, do you
    want to describe when the output changes, or do you just want to
    describe when it should be on? Judicious choice of the default value
    can greatly simplify the coding of the state machine and outputs
    themselves (i.e. state machines only need to describe transitions to
    other states, letting the default assignment take care of waiting in
    the same state).

    If you try to make decisions about this signal or that signal being
    "important" enough to include or exclude a default, you are more
    likely to forget to properly handle something, and get a latch, and it
    is much harder to verify/review that each signal is properly handled.

    Andy
     
    Andy, May 27, 2009
    #10
  11. Weng Tianxiang

    Jacko Guest

    Sound advice. Processes should be separate only for separate
    functional parts. Splitting action into multiple case statements also
    causes errors of logic. 'Inferred latches for signal' is quite a
    strange phrase, maybe 'possible forgotten signal assignment' would be
    better. It only seems to be if ... then ... else ... end if; which
    generates inferred latches. case and if ... then ... end if; does not
    seem to. I guess this is because no else is definite latch/register,
    and case can contain many places of non assignment and so could flood
    the message display. It's not that strange really.

    cheers jacko

    http://nibz.googlecode.com version T much easier to read code. final
    version for a while.
     
    Jacko, May 29, 2009
    #11
  12. Weng Tianxiang

    Andy Guest

    On May 28, 8:32 pm, Jacko <> wrote:
    >'Inferred latches for signal' is quite a
    > strange phrase, maybe 'possible forgotten signal assignment' would be
    > better. It only seems to be if ... then ... else ... end if; which
    > generates inferred latches. case and if ... then ... end if; does not
    > seem to. I guess this is because no else is definite latch/register,
    > and case can contain many places of non assignment and so could flood
    > the message display. It's not that strange really.


    I agree, it is not that strange...

    But it really has nothing to do with missing "else" statements. It
    only has to do with missed assignments. Complex if/elsif or case
    statements just make it much easier to miss an assignment.
    Unfortunately, simply adding an "else" for every "if" is not
    guaranteed to catch every missed assignment.

    If combinatorial processes are needed/desired, the best coding
    mechanism to ensure a latch-free implementation is to include a
    default assignment for every driven signal, right up front in the
    process. This is the simplest coding method to write, review, audit
    and maintain, because then it simply does not matter whether you have
    an "else" for every "if", or an assignment in every branch of a case
    statement.

    Andy
     
    Andy, May 29, 2009
    #12
    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. Weng Tianxiang
    Replies:
    14
    Views:
    1,099
    Martin Thompson
    Mar 11, 2010
  2. Ed McGettigan
    Replies:
    0
    Views:
    484
    Ed McGettigan
    Mar 10, 2010
  3. Andy
    Replies:
    19
    Views:
    910
    Andy Peters
    Mar 22, 2010
  4. fpgabuilder
    Replies:
    3
    Views:
    609
    rickman
    Mar 20, 2010
  5. Andy
    Replies:
    3
    Views:
    505
    fpgabuilder
    Mar 19, 2010
Loading...

Share This Page