Part 5: Finite State Machines

What this lecture covers

This lecture introduces finite state machines (FSMs) as a way to organize sequential hardware behavior in Verilog, answering how a design moves through discrete states based on inputs and a clock. It builds the same circuit - a counter that pulses an LED when done - as both a Moore machine (outputs tied to state) and a Mealy machine (outputs tied to state and input).

By the end you can describe a state machine using localparam constants, a case statement, and multiple always blocks, and you understand the practical difference between blocking (=) and non-blocking (<=) assignment. The lecture closes with a challenge to use a state machine to debounce the button counter built in Part 4.

Key ideas

• Finite state machine: a model with a fixed set of states, transitions between them, and an initial state, used here to structure hardware behavior.
• Moore machine: outputs depend only on the current state; in this design the "done" LED is high only while the state equals done.
• Mealy machine: outputs depend on both current state and inputs, which can let a design use fewer states than the equivalent Moore machine.
• case statement: Verilog's equivalent of switch/case, used here to define per-state behavior and transitions, always paired with a default branch for safety.
• Blocking vs non-blocking assignment: = (blocking) executes assignments in sequence within a clock cycle; <= (non-blocking) evaluates all right-hand sides using values from before the clock edge, so lines effectively execute together - the recommended choice for clocked sequential logic.
• Combinational always @(*): using * in the sensitivity list tells the tool to infer which signals should trigger re-evaluation, typically paired with blocking assignments for unclocked logic.
• Splitting logic across multiple always blocks: separate blocks handle the clock divider, state transitions, the LED counter, and the output logic, which the lecture presents as easier to read even though it could be combined.

Walkthrough

Why state machines, and the Moore design (0:00)

The lecture defines idle, counting, and done states for a circuit that starts counting when a "go" button is pressed, and pulses a "done" LED for one clock cycle once the counter reaches its maximum value before returning to idle. It explains that in a Moore machine, each state directly determines the outputs.

Implementing the Moore FSM in Verilog (3:08)

States are defined as localparam constants, and the design reuses the clock-divider pattern from the previous episode to slow the 12 MHz oscillator down to a visible rate. Separate always blocks handle the clock divider, the state-transition logic (a case statement keyed on the current state register), and the LED counter, deliberately kept apart from the state-transition logic because everything executes concurrently in hardware.

Blocking versus non-blocking assignment (13:22)

Using a worked example with two signals swapping values, the lecture shows that blocking assignment (=) lets each line see the result of the one before it within the same clock edge, while non-blocking assignment (<=) evaluates all right-hand sides first and applies updates simultaneously. The guidance given is to use non-blocking assignment for clocked sequential logic and blocking assignment for unclocked, combinational always blocks.

Building and testing the Moore machine (17:29)

After apio verify, apio build, and apio upload, pressing reset then go starts the counter, which displays on the LEDs and flashes the green LED for one cycle when it finishes.

Converting to a Mealy machine (18:32)

By copying the Moore project and merging the "done" output into the counting-state logic, the design drops the separate done state entirely: the green LED turns on directly when the counter reaches its maximum and the machine returns straight to idle. The lecture notes this trade-off - fewer states and less hardware, at some cost to readability.

Testing the Mealy machine and the debounce challenge (22:39)

The Mealy version is verified, built, and uploaded, and behaves the same way externally. The lecture closes with a challenge: use a Moore or Mealy state machine to debounce the button counter from Part 4 so each press increments the count exactly once.

Before you watch

• Complete Part 4 ("Clocks and Procedural Assignments"); this lecture reuses its clock-divider design and assumes familiarity with always blocks and registers.
• Review the button-debounce issue mentioned in Part 4, since it becomes this episode's challenge.

Check your understanding

1. What is the key difference between how a Moore machine and a Mealy machine produce their outputs?
2. Why does the lecture put the LED counter logic in a separate always block from the state-transition logic?
3. What is the practical difference between blocking and non-blocking assignment inside a clocked always block?
4. Why does the Mealy version of the design need one fewer state than the Moore version?
5. Why does the design include a default case in the state case statement even though every defined state is handled?