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 Foundations57
  • Combinational Design58
  • Sequential Design61
  • FSM & Control66
    • Controller and Datapath
    • Moore vs Mealy
    • State Encoding
      • Encodings Compared
      • Why encoding matters
      • Area and Speed Trade-off
      • Encoding options
      • Binary encoding
      • Illegal States and Recovery
      • Choosing an Encoding
      • One-hot encoding
      • Gray encoding
      • Johnson encoding
      • Key takeaways
      • Worked Examples and Waveforms
    • Multi-Cycle Sequencers
    • UART Transmitter
    • Memory Controller
  • Timing & Clocking64
  • Reset & CDC58
  • Memory & Buses94
  • Advanced RTL60
  • Senior & Interview175
  • Glossary and Notation
Loading lesson

‹State Encoding
  1. Topics
  2. RTL Design
  3. FSM & Control
  4. State Encoding
  5. Choosing an Encoding

Part 4 · FSM & Control · Intermediate

Choosing an Encoding

Which encoding to pick by size, platform and safety needs, and how to keep the RTL flexible.

On this page

    Why this matters

    A state written as a bare number, or a bit tested outside the FSM, ties the whole design to one encoding. Changing the encoding later then means edits in every block and test.

    After this lesson you can: choose a first encoding from size, platform and safety needs, and write the FSM so that the encoding can change without touching other code.

    A practical rule

    Size, platform and safety needs suggest candidates; mapped resource/timing results and the fault contract decide. Illegal-state behaviour still needs a check whichever encoding wins.

    Decision flowchart. If the state is read outside its clock domain, handshake a status snapshot. Otherwise, if faults must be detected, use one-hot or a distance-2 code with a checker. Otherwise, on an FPGA or a large speed-critical FSM, try one-hot and compare reports; else use an enum with binary or the tool's choice.
    A first pass at the choice: crossing first, then fault handling, then platform and size. The mapped reports make the final decision.

    Stop at the first yes. Every branch still keeps the RTL as a named enum, so changing the answer later is a one-line edit.

    Situation

    Encoding

    Small FSM (≤ 8 states), area-sensitive ASIC

    Binary (let the tool choose)

    FPGA, medium or large FSM, speed matters

    Try one-hot; compare target timing/resource reports

    State is read asynchronously or crosses a clock domain

    Handshake a stable status snapshot; raw Gray FSM state or a registered copy alone is insufficient

    Long sequence where each step must decode cheaply

    Johnson

    Safety-critical (fault tolerance matters)

    One-hot or Hamming-distance-2 codes with illegal-state detection

    Unsure

    Write enum and let the tool re-encode

    Write it so the encoding can change

    design.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    // snippet
    // The enum hides the code. Synthesis tools may re-encode it (one-hot, Gray, binary) on request,
    // while the RTL and the testbench stay unchanged.
    typedef enum logic [2:0] {IDLE, START, DATA, PARITY, STOP, ERROR} state_t;
    state_t state, next;
    
    // Vendor attributes (spelling differs by tool) request the encoding without touching the logic:
    //   (* fsm_encoding = "one_hot" *) state_t state;     // Vivado
    //   syn_encoding = "onehot"                            // Synplify-style
    • Use named enum values everywhere, never bare numbers. A change of encoding then changes nothing else.

    • Never decode bits of the state (state[2]) outside the FSM. That bakes the encoding in.

    • Register FSM outputs that need a clean downstream value (see Moore vs Mealy).

    • Check the synthesis log: tools report re-encoded FSMs, so confirm the result matches the intent.

    Common mistakes

    Common pitfall

    Shared numeric state codes and bit-level comparisons couple source behavior to a particular encoding. A manual encoding change can then require edits across blocks and tests, and bit coupling may constrain FSM extraction or recoding. A correct synthesis transformation must preserve defined control-output behavior; silent breakage is not an expected consequence of recoding. Expose named decoded flags and check equivalence under the intended reset/input assumptions.

    The primary Yosys FSM documentation describes extraction of control outputs, including a directly used state bit whose value is preserved as a control output. Detection heuristics and forced encoding attributes have tool-specific limits; inspect the report rather than assuming every enum will be recoded.

    Interview

    Short, strong answer to “binary or one-hot?”: Binary for small, area-driven FSMs. One-hot for larger, speed-driven FSMs, especially on FPGAs. Gray reduces switching on adjacent sequence steps, but audit every branch, abort and reset. Use a CDC handshake for an FSM status snapshot. Always handle illegal states and keep the RTL encoding-agnostic with an enum.

    Check yourself A teammate checks if (state[1]) in a block outside the FSM. What is the risk?

    It couples source behavior to the written code, making manual encoding changes less portable and potentially limiting extraction/recoding. Correct synthesis must preserve that defined output, possibly by retaining decode logic. Expose a named decoded flag and verify equivalence instead of expecting automatic recoding to break semantics.

    Remember

    • Size, platform and safety needs suggest candidates. Mapped resource and timing results, and the fault contract, decide.

    • Use named enum values everywhere, and never decode a state bit outside the FSM.

    • Read the synthesis log: tools report re-encoded FSMs, so check that the result matches the intent.

    Rule of thumb: binary for small area-driven FSMs, one-hot for larger speed-driven ones, and check the log either way.

    Keep going

    • Practice: Mixed encoding hazards when tools re-encode an FSM

    • Practice: Parameterised state width and encoding consistency

    • Interview: run a mock interview on this topic

    Related topics

    • UART transmitter FSM

    Previous

    206 / 694

    Next: One-hot encoding

    Up next

    Up nextOne-hot encoding

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Encodings Compared
    • Why encoding matters
    • Area and Speed Trade-off