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