From 4cdbb16be619788e79066e1887ab2da6d08e6b24 Mon Sep 17 00:00:00 2001 From: Casper Date: Wed, 4 Mar 2026 15:51:51 +0100 Subject: [PATCH] Update FSM description to clarify state management in Verilog implementation Added a note emphasizing that the state should not be modified directly in the solution, and that it is updated only by the always_ff block. This clarification aims to guide users in correctly implementing the FSM logic. --- src/lessons/sv/fsm/description.html | 1 + 1 file changed, 1 insertion(+) diff --git a/src/lessons/sv/fsm/description.html b/src/lessons/sv/fsm/description.html index 04dcf17..c34cc12 100644 --- a/src/lessons/sv/fsm/description.html +++ b/src/lessons/sv/fsm/description.html @@ -33,6 +33,7 @@
  • WRITING — assert sram_we=1 and return to IDLE next cycle

    • Open mem_ctrl.sv. The two-always skeleton and default assignments are already set up. Fill in the case branches inside always_comb: the transition conditions in IDLE, and the output + transition for READING and WRITING.

    +

    Important: Do not modify state in your solution — state is updated only by the always_ff block. In always_comb you only assign to next (and the outputs). The combinational block computes the next state; the flip-flop block applies it on the clock edge.

    Keep outputs in the always_comb block, never in the always_ff block — Moore outputs are a function of state only, not of the current inputs. A Mealy FSM would also allow outputs to depend directly on inputs, giving a one-cycle faster response — but at the cost of glitchy combinational outputs that change mid-cycle whenever inputs change. Moore is the safer default for synchronous RTL.

    Testbench

    The testbench cycles through all three states — idle, write command, read command — and checks that sram_we and ready assert at the right times.