Re: When is it to generate transparent latch or usual combinationallogic?
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
|