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