FPGA Central

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

On May 25, 3:52*pm, Weng Tianxiang <wtx...@gmail.com> 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

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

On May 25, 2:28*pm, Andy <jonesa...@comcast.net> 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

On Mon, 25 May 2009 16:44:28 -0700 (PDT), Weng Tianxiang <[email protected]>
wrote:

>On May 25, 2:28*pm, Andy <jonesa...@comcast.net> 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,

>Hi Andy,

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

Search for "Single Process State Machine" - it has been described many times on
this group and it is the usual way to avoid combinatorial processes in your
example - to avoid precisely the problem that you took a week to find.

- Brian

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

On May 26, 5:58*am, Andy <jonesa...@comcast.net> 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

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

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

On May 26, 3:21*pm, Andy <jonesa...@comcast.net> 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

On May 26, 7:22*pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On May 26, 3:21*pm, Andy <jonesa...@comcast.net> 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

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.

On May 28, 8:32*pm, Jacko <jackokr...@gmail.com> 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