Use of latches in FSMs

[Ehsan]

Hello,

I have read in many places that the outputs of a finite state machine must be set to their default values in order to avoid unwanted latches. However, I have a design of an FSM in my mind in which some outputs at some states must keep their old values. For example assume "a" is an output of the FSM. Depending on the state, it can have one of these three assignments:

a <= '0';
a <= '1';
a <= a;

My question is if this is a good and common practice in designing FSMs for FPGAs, i.e. if we latch some outputs at some states.

Thanks!

 

[glen herrmannsfeldt]

Ehsan <ehsan.hosseini@gmail.com> wrote:

I have read in many places that the outputs of
a finite state machine must be set to their default
values in order to avoid unwanted latches.

Unwanted latches come from the way behavioral verilog
(and I believ VHDL) work. It is a separate question.

However, I have a design of an FSM in my mind in
which some outputs at some states must keep their
old values. For example assume "a" is an output
of the FSM. Depending on the state, it can
have one of these three assignments:

a <= '0';
a <= '1';
a <= a;

This is the difference between Mealy and Moore machines.
That only matters if you use a FSM generator. Otherwise,
you can do anything that make logical sense.

My question is if this is a good and common practice
in designing FSMs for FPGAs, i.e. if we latch some
outputs at some states.

Good practice might be using a, more or less, standard
design for a Mealy or Moore machine.

-- glen

 

[KJ]

On Monday, December 23, 2013 3:55:45 PM UTC-5, Ehsan wrote:

Hello,



I have read in many places that the outputs of a finite state machine must be set to their default values in order to avoid unwanted latches. However, I have a design of an FSM in my mind in which some outputs at some states must keep their old values.

You're misinterpreting what you've read. The 'assignment of a default value to avoid latches' comes up IF you choose to write your FSM in the form of a blob of combinatorial logic followed by a register. However, you can choose to write your FSM in the form of a single clocked process that completely avoids this problem. Google this and comp.lang.vhdl for 'two process state machine' and you'll likely hit on all kinds of banter on the subject. Don't believe any of the proponents of the 'two process' (or three process) approach when they discuss why 'two process' is superior (it's not).

The bottom line is:
- Writing it in the 'two process' form gains you nothing and will cost you in terms of spending time with extra typing and extra verifying that you haven't overlooked some signal inside the combinatorial process.
- What you've read is not limited to FSMs, it applies to any synchronous description.

For example assume "a" is an output of the FSM. Depending on the state, it can have one of these three assignments:

a <= '0';

a <= '1';

a <= a;

Assuming that this is not combinatorial logic (i.e. the 'a' is an output of a flip flop), then all of the above would be OK. If 'a' is not the output of a flip flop, then the last assignment would create a form of latch which would not be good in an FPGA design.

My question is if this is a good and common practice in designing FSMs for FPGAs, i.e. if we latch some outputs at some states.

Your question seems to have nothing to do with anything previous. The 'good and common practice' is to accurately describe your design while avoiding descriptions that result in a signal feeding back into its own logic without a flip flop in between. If you're asking is it OK to have 'a' not change value while in a particular state, then yes that is very commonly done. A simple example is a counter that has a count enable. If the count enable is true, then you count, if not then the count remains unchanged.

Kevin Jennings

 

[Ilya Kalistru]

вторник, 24 декабря 2013 г., 0:55:45 UTC+4 пользователь Ehsan написал:

Hello,



I have read in many places that the outputs of a finite state machine must be set to their default values in order to avoid unwanted latches. However, I have a design of an FSM in my mind in which some outputs at some states must keep their old values. For example assume "a" is an output of the FSM. Depending on the state, it can have one of these three assignments:



a <= '0';

a <= '1';

a <= a;



My question is if this is a good and common practice in designing FSMs for FPGAs, i.e. if we latch some outputs at some states.



Thanks!

If you made something like this:

process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
state <= first;
...
else
case state is
when first =>
a<= '0';
state <= second;
when second =>
a<= '1';
state <= third;
when third =>
a<= a;
state <= first;
when others => null;
end case;
end if;
end if;
end process;

there is no latches at all! Latches may arise in combinatorial logic. In fully clocked logic there is no latches.

Moreover, you can omit "a<=a;" in most cases:

process(clk)
begin
if rising_edge(clk) then
if reset = '1' then
state <= first;
...
else
case state is
when first =>
a<= '0';
state <= second;
when second =>
a<= '1';
state <= third;
when third =>
state <= first;
when others => null;
end case;
end if;
end if;
end process;

 

On Tuesday, December 24, 2013 10:02:17 AM UTC-6, Ilya Kalistru wrote:
> Moreover, you can omit "a<=a;" in most cases:

In a clocked process, you will usually get a "removing redundant assignment" warning (harmless, except it is one more warning you have to look at and dismiss after every synthesis run).

But keep in mind, in the given registered process, 'a' becomes the output of an inferred register.

If the OP is wanting a combinatorial output decoded from the state register, then having a combinatorial output remember its last value will create a latch, no matter how you do it. You could create an additional register which "remembers" the last output value, and select the output of that register when it is desired to not change the output value.

Or you can create a registered output that is set whenever the state is assigned to the desired states for that output. If the output is desired to be a function of only the state, then this is fairly simple. If the output is desired to be a function of the state and other inputs, it gets more complex, but is certainly doable.

Andy

 

[Ilya Kalistru]

>>If the OP is wanting a combinatorial output decoded from the state register

How it can be useful?

 

On Thursday, December 26, 2013 12:23:50 PM UTC-6, Ilya Kalistru wrote:

If the OP is wanting a combinatorial output decoded from the state register
How it can be useful?

I'm not sure exactly what you are asking.

Why someone would create outputs which are merely decoded from the state? Because they can? If the state machine is one-hot encoded and the output is only asserted for one state, then the bit for that state IS the output.

Otherwise, as long as the decoded outputs are sampled on the same clock as the FSM, decoding glitches don't matter.

Combinatorial state machine outputs are one of the few good reasons to use a 2-process coding pattern. It is possible to create combinatorially decoded outputs from an FSM in a single, clocked VHDL process, but it requires a separate case statement from the next-state-assigning case statement and the state register has to be a variable instead of a signal.

Andy