Moore and Mealy

Usual Moore machines don't have necessarily synchronous outputs, see e.g. the Moore HDL template in Quartus. It assigns outputs in a combinational case structure which can have glitches as well.

The glitches will be only noticed when processing the state machine output asynchronously or using them as external outputs.

The basic Moore machine description in literature however doesn't exactly specify how outputs are generated. You can write a Moore machine in a single synchronous process, that assigns both state variable and outputs to registers.

I usually differentiate the two as follows:

Moore --> outputs (synchronous or asynchronous) are dependented on only the state of the FSM

Mealy --> outputs (sync or async) are dependent on the state and inputs of the FSM

When designing I typically try to implement moore style FSMs; however that doesn't work when your statemachine needs to drive other logic based on immediate changes to the stimuli. So depending on the pipelining of your logic surrounding the FSM moore implementations are not always possible because it might cause your FSM to drive outputs too late.

Normally I do a hybrid where the state machine is a moore FSM with some additional conditioning logic added to the outputs after the FSM to give it 'mealy like' timing for all the stuff downstream. For me I find it's easier to code that way rather than implementing a mealy FSM directly, but the functionality is the same.

Thank you very much folks.

I am still a bit confused about the word glitch. When you read that Mealy machines can cause glitches at the output. Does that imply if the input glitches for whatever reason that glitch will be observed at the output.

A mealy machine in the 'pure' form is usually combinational logic combining the state register with the inputs to the FSM. So I guess because the inputs are combined combined the state register output it is more suceptible to glitches. I don't really consider the FSM type factors in glitch/glitch free outputs since the output of a moore machine can have glitches too due to various delays through combinational logic that might be between the state registers and the output. I would say mealy FSMs on average have more glitch time than moore FSMs but even that's a generalization that isn't always true.

When I design FSMs I don't even worry about what type it is. Typically I just care about simplicity and keeping combinational delays to a minimum. Whether it's a moore or mealy, if it gets the job done and hits the Fmax I want then I don't really care what type it is :)

Read the following document that shows a progression of how to design an interface to a synchronous bus.

Page 31 shows glitches that can be created by using asynchronous state machine outputs.

Note how the FSM designs are a mixture of Mealy and Moore signals, eg., see p35. The Mealy outputs are shown in the ASM charts on transitions, whereas the Moore outputs are within the state boxes. The outputs from either can be registered to ensure they are glitch-free, however, those signals will then be delayed by one clock, so they need to be generated in the ASM chart one clock earlier.

Cheers,

Dave

--- Quote Start ---

Thank you very much folks.

I am still a bit confused about the word glitch. When you read that Mealy machines can cause glitches at the output. Does that imply if the input glitches for whatever reason that glitch will be observed at the output.

--- Quote End ---

A glitch is temporary unintended change of state in a signal, caused by different delay paths.

Both Moore and Mealy FSMs can produce glitches in their outputs.

In case of Moore FSMs, these come from the skew between FF outputs and also the different delay paths in the output combinational logic.

In the case of a Mealy FSM, in addition to the ones before, the combinational paths from the inputs to the outputs will also produce glitches.

Glitches are common, actually.

One of the advantages of synchronous logic is that, as long as timings are met, glitches will not affect the function of the circuit.

If you can't avoid them, then having your outputs driven directly from registers is a good way to avoid them.