Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
    • Controller and Datapath
    • Moore vs Mealy
    • State Encoding
    • Multi-Cycle Sequencers
    • UART Transmitter
    • Memory Controller
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹RTL Design
  1. Topics
  2. RTL Design
  3. FSM & Control

Part 4 · FSM & Control · Intermediate

FSM & Control

FSM control: controller/datapath structure, outputs, encoding, and three complete controllers.

  • 6topics
  • 27lessons

Control logic decides what happens and when. A finite state machine implements it with a state register, next-state logic, and outputs.

Learning path through the FSM topics.
Suggested order. The first three topics set the vocabulary; the last three apply it.

Topic

Lessons

After it you can…

Study time

Controller and datapath

6

Split a design into datapath and controller and code the FSM in two processes.

2–3 h

Moore vs Mealy

4

Choose an output style and register outputs when needed.

1–2 h

State encoding

4

Compare binary, Gray, one-hot and Johnson; handle illegal states.

2 h

Multi-cycle sequencers

4

Build a shift-add multiplier and a latency-aware memory reader with timeout and abort.

3 h

UART transmitter

5

Design and verify a complete serial transmitter.

2–3 h

Memory controller

4

Write a request/response controller and prove it with a scoreboard and mutations.

2–3 h

Study time covers reading each lesson and running its examples. The section's hands-on project takes extra hours on top.

Tip

A finished FSM needs three answers: the state after reset, the behavior in unreachable states, and the outputs on idle cycles. Most FSM bugs hide in those three places.

Check yourself Before starting the section, can you say why an FSM's combinational block should begin with default assignments?

So every output and the next state is assigned on every path. Anything left unassigned on some path becomes a latch. The coding rules lesson shows the latch Yosys reports when a default is missing.

Interview

Screening tasks from this section: a sequence detector (Moore and Mealy), a GCD or multiplier controller, a traffic-light or vending-machine FSM, a UART transmitter, and “what happens if the state register flips a bit?”.

End-of-section checkpoint

Use these four questions to decide whether you are ready to move on: explain, predict, implement and debug. If one is shaky, each answer names the lesson to revisit. New readers can skip this until they finish the section.

Check yourself Explain: how do Moore and Mealy outputs differ in timing, and what does that cost?

A Moore output depends only on the state, so it changes one clock after the input that caused it and is decoded from the state register alone, never from a live input. A Mealy output also depends on the inputs, so it can react in the same cycle, but it is combinational from input to output: it can glitch and it adds to the next block's timing path. Revisit Moore and Mealy: the behavioral difference.

Check yourself Predict: a controller has 5 states. How many flops do binary and one-hot encodings need, and which usually has simpler next-state logic?

Binary needs 3 flops (ceiling of log2 5); one-hot needs 5. One-hot usually has simpler, shallower next-state and output decode, because each state is one bit, which is why it is common in FPGAs and fast paths; binary saves flops. Revisit Encodings compared.

Check yourself Implement: a Mealy detector for the overlapping sequence 101. Which state does it go to after detecting it?

States: S0 (nothing), S1 (seen 1), S10 (seen 10). From S10, an input 1 completes 101: the output is 1 and the next state is S1, because that last 1 can start the next match (10101 gives two detections). A non-overlapping detector would return to S0 instead. Revisit Side-by-side sequence detector.

Check yourself Debug: after a supply glitch, a binary-encoded FSM sits forever in an encoding that is not one of its states. What was missing?

A default in the next-state case that returns to a safe state (and ideally flags the error). Without it, an unused encoding has no defined exit and the FSM can stay there. Revisit Illegal states and recovery.

How this was checked

Authors can compile complete examples with node scripts/tools/check-rtl-snippets.mjs rtl/fsm and execute self-checking benches with node scripts/tools/run-rtl-testbenches.mjs rtl/fsm. These are separate validation commands, not an established every-build gate. Partial snippets and deliberately broken examples have documented exclusions in those scripts.

Coverage is bounded by each bench: GCD enumerates the 961 positive pairs in 1..31 at width 8, then exercises directed interface cases. That is not every 8-bit input or every parameter configuration.

Several lessons report mutation results: deliberately break the design and require the checker to reject it. Record source revision, simulator/tool versions, command, exclusions and final verdict when rerunning. Every self-checking bench in this section prints PASS under those commands; mutation results are rerun only where a lesson says so.

Waveforms illustrate the stated sampling convention; compare them with a fresh simulation of the same revision before treating them as execution evidence. Functional checks do not establish physical timing or mapped fault recovery.

Related topics

  • Previous: Sequential design

  • Next: Timing

PreviousNext: Controller and Datapath

Up next

Up nextController and Datapath

Sign in to save progress

Practice this lessonReport an error

See also

  • RTL Foundations
  • Combinational Design
  • Sequential Design