When is it to generate transparent latch or usual combinationallogic?

W

Weng Tianxiang

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
 
D

Dave

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
Click to expand...

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
 
A

Andy

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
 
W

Weng Tianxiang

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
Click to expand...

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
 
A

Andy

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
 
W

Weng Tianxiang

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
Click to expand...

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
 
M

Mike Treseler

Andy said:
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;
Click to expand...

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
 
A

Andy

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
 
W

Weng Tianxiang

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
Click to expand...

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
 
A

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 -
Click to expand...

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
 
J

Jacko

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

Andy

'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.
Click to expand...

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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Why doesn't this situation generate a latch? 14
These no else statements generate latches? 2
Problem With Mealy Sequence Detector 1
How dofor using generate or loop for this process ? 3
LFSR doesn't generate random values during simulation 1
Two processes with communication through a signal. 5
inconvenience latch 1
VHDL and Latch 31

Members online

No members online now.
Total: 31 (members: 1, guests: 30)
Robots: 419

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top