Use of latches in FSMs

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

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

-- glen

t be set to their default values in order to avoid unwanted latches. Howeve r, I have a design of an FSM in my mind in which some outputs at some state s must keep their old values.

You're misinterpreting what you've read. The 'assignment of a default valu e 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 ch oose to write your FSM in the form of a single clocked process that complet ely avoids this problem. Google this and comp.lang.vhdl for 'two process s tate 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 ha ven't overlooked some signal inside the combinatorial process.

- What you've read is not limited to FSMs, it applies to any synchronous de scription.

t can have one of these three assignments:

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 whic h would not be good in an FPGA design.

r FPGAs, i.e. if we latch some outputs at some states.

Your question seems to have nothing to do with anything previous. The 'goo d and common practice' is to accurately describe your design while avoiding descriptions that result in a signal feeding back into its own logic witho ut a flip flop in between. If you're asking is it OK to have 'a' not chang e 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

???????, 24 ?????

???????? Ehsan ??? ????:

t be set to their default values in order to avoid unwanted latches. Howeve r, I have a design of an FSM in my mind in which some outputs at some state s must keep their old values. For example assume "a" is an output of the FS M. Depending on the state, it can have one of these three assignments:

r FPGAs, i.e. if we latch some outputs at some states.

If you made something like this:

process(clk) begin if rising_edge(clk) then if reset = '1' then state a

How it can be useful?

ster

I'm not sure exactly what you are asking.

Why someone would create outputs which are merely decoded from the state? B ecause 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 decode d 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 th e state register has to be a variable instead of a signal.

Andy