Sequential Logic and State Machines

• Latches versus flip-flopsA latch is level-sensitive: it is transparent while its enable is asserted. A flip-flop is edge-sensitive: it samples only at the clock edge. Almost all synchronous design uses edge-triggered D flip-flops, because transparency windows make timing analysis intractable.
• Setup and hold timeData must be stable for t_setup before the clock edge and t_hold after it. Violate either and the flip-flop's output is undefined for an unbounded time. These two numbers, plus the clock-to-output delay, are the entire basis of synchronous timing analysis.T_clk >= t_clk-to-q + t_logic + t_setup + t_skew. Hold violations are not fixed by slowing the clock.
• The synchronous design disciplineOne clock, every flip-flop clocked by it, no gated clocks, no combinational logic in clock paths, all inputs from other domains synchronised at the boundary. This discipline is what makes a design analysable and reliable. Every deviation must be deliberate and justified.
• Reset: synchronous, asynchronous, and releaseAn asynchronous reset takes effect immediately regardless of the clock, which is what you want at power-up when the clock may not be running. But its release must be synchronised, or different flip-flops leave reset on different cycles. The standard solution is asynchronous assert, synchronous de-assert.
• Metastability and synchronisersAny signal crossing from another clock domain, or from the asynchronous outside world, will eventually violate setup or hold. The flip-flop then enters a metastable state that resolves after an unpredictable time. A two-flip-flop synchroniser gives the metastability time to decay; it does not eliminate the risk, it makes the mean time between failures astronomically long.Two-stage synchroniser on every asynchronous input. Never fan out an unsynchronised async signal to more than one destination.
• Moore versus Mealy machinesA Moore machine's outputs depend only on the current state, so they are glitch-free and registered-clean but respond one cycle later. A Mealy machine's outputs depend on state and inputs, so they respond immediately but can glitch. Choose Moore unless you need the extra cycle of latency back.
• State encodingBinary encoding minimises flip-flops; one-hot encoding minimises the next-state logic and is faster and easier to debug, at the cost of one flip-flop per state. Gray encoding minimises simultaneous bit changes, which matters when the state crosses a clock domain. Also decide what happens in unreachable states — a safe FSM returns to a known state.
• Counters, dividers and enablesClock division by gating the clock is a mistake in almost all cases; instead run everything on one clock and use a clock-enable signal generated by a counter. This preserves the synchronous discipline while giving you the slower rate you wanted.

ProblemA mechanical button feeds a 50 MHz synchronous system. Design an FSM that produces a single-cycle pulse per press, ignoring bounce up to 10 ms, and handles the fact that the button is asynchronous.

1. 1
   Step 1 - synchronise. The button is asynchronous, so it must pass through a two-flip-flop synchroniser before touching any logic. btn_sync = second flip-flop output. This is non-negotiable and is where most beginner designs fail.
2. 2
   Step 2 - size the debounce counter. 10 ms at 50 MHz is 500,000 clock cycles. That needs ceil(log2(500000)) = 19 bits.
3. 3
   Step 3 - define states. IDLE (waiting for a press), COUNT_PRESS (input has gone active, waiting for stability), PRESSED (pulse emitted, waiting for release), COUNT_RELEASE (input has gone inactive, waiting for stability).
4. 4
   Step 4 - transitions. IDLE: if btn_sync asserted, clear counter and go to COUNT_PRESS. COUNT_PRESS: increment counter; if btn_sync de-asserts, return to IDLE (it was a bounce); if counter reaches 500000, go to PRESSED. PRESSED: emit the pulse for one cycle, then wait for btn_sync to de-assert, then go to COUNT_RELEASE. COUNT_RELEASE: mirror of COUNT_PRESS.
5. 5
   Step 5 - output style. The single-cycle pulse should be a Moore output asserted only in a dedicated one-cycle state, so it is glitch-free and exactly one cycle wide. A Mealy output here would be a combinational function of btn_sync and could glitch.
6. 6
   Step 6 - encoding. Four states, so 2 bits binary or 4 bits one-hot. At 50 MHz with trivial next-state logic, binary is fine. Define the two unused binary codes to transition to IDLE, so a corrupted state recovers.
7. 7
   Step 7 - reset. Asynchronous assert so the FSM is in IDLE the instant power comes up; synchronous de-assert via a reset synchroniser so all flip-flops leave reset on the same edge.
8. 8
   Step 8 - timing check. The critical path is the 19-bit counter's comparator to the next-state logic to the state register's D input. At 50 MHz the budget is 20 ns. A 19-bit magnitude comparison against a constant is cheap (compare only the bits that are 1 in the constant), so this passes easily. If it did not, the fix would be to compare against a power of two and use the carry-out.
9. 9
   Step 9 - verification plan. Test vectors must include: a clean press, a press with 20 bounce transitions, a press shorter than 10 ms (must be rejected), a press held for 10 seconds (must produce exactly one pulse), and a release with bounce.

AnswerTwo-flip-flop synchroniser, a 19-bit debounce counter, a four-state Moore FSM with a dedicated one-cycle pulse state, binary encoding with unused states routed to IDLE, and asynchronous-assert/synchronous-de-assert reset. The synchroniser and the Moore output style are the two decisions that separate a working design from an intermittent one.

Tool: Digital (hneemann) sequential simulation with a clock and measurement graph

• In Digital, place a Clock component (Components > IO) and set its frequency for simulation.
• Build the two-flip-flop synchroniser: two D flip-flops in series, both clocked from the same clock, input from a manual Input component representing the button.
• Build a counter: use the built-in Counter component (Components > Memory) with a scaled-down terminal count, e.g. 16 instead of 500000, so you can watch it in reasonable simulation time. Note in your write-up that the real value is 500000.
• Build the state register with a D flip-flop pair (2-bit binary state) and the next-state logic with gates or a lookup table.
• Wire the outputs and add Probe components (Components > Misc) on the state bits, the synchroniser output, and the pulse output.
• Open Analysis > Measurement Graph and run the clock. You now have a waveform view.
• Toggle the button input rapidly to simulate bounce and watch the state machine ignore the transitions until the counter completes.
• Add a Test Case component with a clock-cycle-by-clock-cycle vector table. Digital's test syntax supports loops and clock steps, so you can encode 'assert button, bounce it 5 times, hold for 20 cycles, expect exactly one pulse'.
• Run the test and confirm it passes. Then deliberately remove the synchroniser and observe that the test still passes in simulation — an important lesson: simulation will not show you metastability. The synchroniser is justified by analysis, not by simulation.

• All About Circuits - Digital, sequential circuitsfreereading~180 minMultivibrators, flip-flops, counters, shift registers and state machines. Chapters 10-12.
• nand2tetris Part I - projects 3 (sequential logic) and 5freecourse~240 minBuild registers, RAM and a program counter from flip-flops, with an automated grader. Free materials.
• Ben Eater - clock module and CPU control logic videosfreevideo~180 minWatch the clock, register and control-logic episodes. Seeing setup/hold and control sequencing on a real breadboard with a scope makes the abstractions concrete.
• Metastability and synchroniser design (vendor app notes)freereference~60 minSearch for 'metastability' in FPGA vendor documentation. The MTBF calculation and the two-flip-flop synchroniser justification are covered rigorously and freely.

Design and verify a synchronous controller with at least six states that interacts with the asynchronous outside world — for example a traffic light with a pedestrian request button, a vending machine coin controller, or a stepper motor sequencer with limit switches.

Deliverables

• A written specification including all inputs, outputs, timing requirements in real units, and the required behaviour on reset and on invalid input combinations.
• A state transition diagram with every state and every transition labelled with its condition, drawn clearly enough to be reviewed by someone else.
• A state transition table and an output table, with the encoding chosen and justified (binary, one-hot or Gray) and the handling of unreachable states stated.
• A Moore/Mealy decision documented per output, with the reason.
• A synchroniser on every asynchronous input, identified explicitly in the schematic or diagram.
• A reset strategy: asynchronous assert with synchronous de-assert, with the reset synchroniser shown.
• A working implementation in Digital or Logisim-evolution with a waveform capture showing a complete pass through the main state sequence.
• An automated test-vector suite covering: every state entered at least once, every transition exercised at least once, reset from each state, and at least two invalid or adversarial input sequences. State your transition coverage as a percentage.
• A timing analysis: the critical path through the next-state logic, the resulting maximum clock frequency, and a statement of the actual clock frequency and the margin.

Acceptance criteria — how you know it is good enough

• Every asynchronous input passes through a two-flip-flop synchroniser before any logic.
• Reset is asynchronous-assert, synchronous-de-assert, and this is visible in the implementation.
• Unreachable states have a defined transition to a safe state.
• The test suite achieves 100% state coverage and states its transition coverage explicitly.
• The critical path is identified specifically and converted to a maximum frequency with margin stated.
• No gated clocks are used; slower rates are achieved with clock enables.

If you want to push further

• Add a second clock domain and design a correct handshake (or a small asynchronous FIFO) to move data across it. Explain why a single synchroniser on a multi-bit bus is insufficient.
• Compute the metastability MTBF for your synchroniser using the standard formula and typical flip-flop parameters, and state how many years it corresponds to.

• I can explain setup, hold and clock-to-output and use them in a frequency calculation.
• I synchronise every asynchronous input with two flip-flops, without exception.
• I use asynchronous-assert, synchronous-de-assert reset and can explain why.
• I choose Moore or Mealy deliberately per output and can justify the choice.
• I define behaviour for unreachable states so a corrupted machine recovers.
• I avoid gated clocks and use clock enables instead.
• I verify FSMs with coverage-driven test vectors, not by clicking through the happy path.