How a state machine is constructed using latches?

[Weng Tianxiang]

Actually, I'm not certain the code you show (that I got from the
Lattice Logic Block Editor) is exactly the same as my VHDL
description.  For them to match, the latch enable would have to have
priority over the reset and that is not a very normal feature in a
latch.

case CombReg is
  when '0' =>
    if (C01 = '1') then
      Comb <= '0';
    elsif (C02 = '1') then
      Comb <= '1';
    else
      -- Here an assignment statement is missing, but it doesn't
      -- generate latch.  It is treated as a null statement. -Weng
    end if;
  when others =>
    Comb <= '1';
end case;

Notice that once the latch is set to a '1' in the VHDL, there is no
way to clear it.  When CombReg is a '1', the "others" clause of the
case is executed which only allows it to be a '1'.  The async clear
can only be asserted when CombReg is a '0'.  Of course, Comb and
CombReg are not the same signals, so there is a window between the
latch being set and the Register output going high where the latch can
be reset by C01.

There are only four inputs to this logic function "Comb".  A LUT4 can
implement ***ANY*** logic function of 4 inputs.  So there certainly is
a way to implement the above VHDL in a single LUT4.  In fact, you
don't even need the latch.

Comb <= CombReg or (C02 and not C01) or (Comb and not C01);

If you want to use the built in Latch in the FPGA, then I guess you
have to use a LUT4 to generate the enable and another to generate the
data (or async clear).

Enable <= CombReg or C01 or C02;
DataIn <= CombReg or not C01;

There is no savings by only using 2 of the 4 inputs on a LUT4 but
there is some advantage to using the reset input to a Latch.  I think
it may avoid potential race conditions when only one input switches.
My logic will have some problems, for example CombReg = 0, C02 = 0 and
C01 = 1.  Bring C01 low and it will either stay clear or set the latch
depending on which of the two paths are faster.  Hmmm, maybe the tools
aren't so stupid after all.  In essence, they are using the enable as
a set and the async reset as a... well, a reset!

Rick

Rick

Actually it is not the fault of Lattice, but of your VHDL code.

In your example,

case CombReg is
when '0' =>
if (C01 = '1') then
Comb <= '0';
elsif (C02 = '1') then
Comb <= '1';
else
-- Here an assignment statement is missing, but it doesn't
-- generate latch. It is treated as a null statement. -Weng
end if;
when others =>
Comb <= '1'; <-- lock here by VHDL, not by Lattice compiler
end case;

Process_1 : process(RESET, CLK)
begin
if (RESET = '1') then
LatchReg <= '0';
CombReg <= '0';
elsif (rising_edge(CLK)) then
LatchReg <= Latch;
CombReg <= Comb; <-- lock here by VHDL, not by Lattice
compiler
end if;
end process;

Weng

 

[rickman]

      CombReg   <= Comb; <-- lock here by VHDL, not by Lattice

Weng

Who said anything about it be the fault of the tools? I said that it
appeared there was a difference, but then I realized that the async
reset must have priority over the latch enable because it can still be
reset once set up to the point that the value of Comb is captured by
CombReg. Then there is no longer a way to reset the latch.

This is the sort of stuff that makes working with latches difficult.
If the combinatorial logic had been described in the sequential
process, there would have been no possibility of generating a latch.

Rick

 

[Andy]

If the combinatorial logic had been described in the sequential
process, there would have been no possibility of generating a latch.

Amen!

Andy

 

[Weng Tianxiang]

Amen!

Andy

Rick,
Try this one and there is no lock problem any more in VHDL. See what
happens.

CombProc : process(CombReg, C01, C02)
begin
case CombReg is
when '1' => <-- only change, and not locked again
if (C01 = '1') then
Comb <= '0';
elsif (C02 = '1') then
Comb <= '1';
else
null;
end if;
when others =>
Comb <= '1';
end case;
end process;

Thank you.

Weng