When is it to generate transparent latch or usual combinational logic?

On May 26, 7:22=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On May 26, 3:21=A0pm, 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
> > =A0 =A0if rising_edge(CLK) then
> > =A0 =A0 =A0 turn_on <=3D '0';
> > =A0 =A0 =A0 if SINI =3D '1' then
> > =A0 =A0 =A0 =A0 State2 <=3D Idle_S;
> > =A0 =A0 =A0 else
> > =A0 =A0 =A0 =A0 case State2 is
> > =A0 =A0 =A0 =A0 when Idle_S =3D>
> > =A0 =A0 =A0 =A0 =A0 if A1 =3D '1' then
> > =A0 =A0 =A0 =A0 =A0 =A0 turn_on <=3D '1';
> > =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D X_S;
> > =A0 =A0 =A0 =A0 =A0 end if;
> > =A0 =A0 =A0 =A0 when X_S =3D>
> > =A0 =A0 =A0 =A0 =A0 if A2 =3D '1' then
> > =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D Idle_S;
> > =A0 =A0 =A0 =A0 =A0 end if;
> > =A0 =A0 =A0 =A0 end case;
> > =A0 =A0 =A0 end if; -- sini
> > =A0 =A0end 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 <=3D 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 <=3D 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=A0pm, 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