FSM — Architecture & Fundamentals

The fundamental control structure behind protocols, sequencing, and decision logic.

1. Introduction

A Finite State Machine (FSM) is one of the most essential building blocks in digital design.
It defines how a system reacts to inputs, transitions between states, and produces outputs.

FSMs appear everywhere:

• protocol controllers
• bus interfaces
• arbitration logic
• initialization sequences
• error handling
• power‑up and reset flows
• pipeline control

Despite their apparent simplicity, FSMs encode the behavior of a system, and their correctness is critical for reliability and maintainability.

2. What an FSM Does

An FSM:

• holds a current state
• evaluates inputs
• computes the next state
• produces outputs

It is the digital equivalent of a decision‑making engine.

Typical use cases:

• sequencing operations
• enforcing protocol rules
• coordinating multiple blocks
• managing retries and timeouts
• controlling datapath activation

3. FSM Architecture Overview

An FSM typically consists of:

• State register
• Next‑state logic
• Output logic
• Optional timers or counters
• Optional error states

Block Diagram (concet)

          +-----------------------+
Inputs →  |   Next-State Logic    | → Next State
          +-----------------------+
                     ↓
               +------------+
               | State Reg  |
               +------------+
                     ↓
          +-----------------------+
          |     Output Logic      | → Outputs
          +-----------------------+

4. Types of FSMs

A) Moore Machine

• Outputs depend only on the current state
• More stable, easier to verify
• Often preferred in safety‑critical designs

B) Mealy Machine

• Outputs depend on state + inputs
• Lower latency
• More compact logic
• Requires careful handling to avoid glitches

C) One‑Hot FSM

• One flip‑flop per state
• Fast, simple next‑state logic
• Common in FPGAs

D) Binary‑Encoded FSM

• Compact state representation
• Fewer flip‑flops
• More complex next‑state logic

E) Gray‑Encoded FSM

• Only one bit changes per transition
• Useful for minimizing switching noise

5. Key Concepts

A) State Encoding

Impacts area, speed, and power.

B) Reset Strategy

FSMs must start in a known, safe state.

C) Illegal States

Must be handled explicitly to avoid lock‑ups.

D) Determinism

FSMs must behave predictably under all input combinations.

E) Timing Closure

FSMs often sit on critical paths due to combinational next‑state logic.

6. System‑Level Perspective

From a system‑level viewpoint, FSMs define behavioral correctness.

They ensure:

• protocol compliance
• correct sequencing
• safe error recovery
• deterministic behavior
• predictable latency

A system architect uses FSMs to:

• enforce rules
• coordinate subsystems
• manage retries and timeouts
• implement safety mechanisms
• define initialization flows

FSMs are the backbone of:

• bus controllers
• communication protocols
• power management units
• safety monitors

7. Block‑Level Perspective

At block level, FSMs are an RTL discipline.

Key implementation topics:

• clean state encoding
• glitch‑free outputs
• separation of next‑state and output logic
• synchronous resets
• safe handling of illegal states
• timing closure on next‑state logic

Common pitfalls:

• mixing combinational and sequential logic
• missing default assignments
• unintended latches
• glitchy Mealy outputs
• unreachable or dead states
• no recovery from illegal states

8. Best Practices for FSM Implementation

A) Use Enumerated Types (SystemVerilog / VHDL)

Improves readability and reduces errors.

B) Separate Logic Clearly

• one block for state register
• one block for next‑state logic
• one block for outputs

C) Define a Safe Reset State

Especially important in automotive, radar, and safety‑critical systems.

D) Handle Illegal States

Use:

• default transitions
• safe fallback states
• synthesis pragmas (optional)

E) Keep Outputs Registered

Avoids glitches and improves timing.

9. FSM and CDC

FSMs often interact with signals crossing clock domains.

Best practices:

• synchronize all external inputs
• avoid Mealy outputs driven by asynchronous signals
• ensure state transitions depend only on synchronized signals

FSMs must never directly consume:

• xxx_meta
• unsynchronized buses
• asynchronous pulses

10. Related Content

Learning Paths

• Block‑Level Design Path
  FSM as the core control structure in RTL design
• System‑Level Design Path
  FSM as the behavioral backbone of protocols and sequencing

11. Summary

FSMs are the heart of digital control logic.
They define how systems behave, react, and recover from errors.

A well‑designed FSM is:

• deterministic
• safe
• maintainable
• easy to verify
• robust under all conditions

This page provides the foundation for more advanced topics such as:

• protocol controllers
• arbitration logic
• safety‑critical state machines
• power‑up sequencing
• error recovery mechanisms

12. Related Pages

• Data Path — Architecture & Fundamentals
  The structural backbone that defines how data moves, how latency and throughput are balanced, and how control logic interacts with the datapath.
• Arbiter — Architecture & Fundamentals
  Priority‑based and fair‑sharing mechanisms that often work alongside FSMs to coordinate access to shared resources.
• FIFO — Architecture & Fundamentals
  Elastic buffering and rate‑matching structures frequently controlled or supervised by FSM logic.
• LFSR & PRBS — Overview, Families & Architecture
  Deterministic sequence generators often used as pattern sources or scramblers under FSM control.
• CRC — Overview, Families & Architecture
  Error‑detection blocks commonly orchestrated by FSMs in protocol controllers and data‑integrity pipelines.