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
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
    • Low-Power RTL Hub
    • DFT and Scan Hub
    • Physical Awareness Hub
    • Waveform Debug Hub
    • STA and ECO Hub
    • RTL-to-Implementation Closure
    • DFT-Ready RTL
    • Capstone: Resilient Streaming Peripheral
    • Principal Design Review
    • Senior RTL Interview Questions & Model Answers
      • Interview: Combinational and Arithmetic
      • Interview: Sequential and Pipelines
      • Interview: FSM and Control
        • Choosing an FSM Encoding from Timing
        • Moore vs Mealy Outputs
        • Proving an FSM Correct
        • The Controller and Datapath Split
      • Interview: Timing and STA
      • Interview: CDC and Reset
      • Interview: Memories and Buses
      • Interview: Low-Power Design
      • Interview: Debug and ECO
      • Interview: Coding and Whiteboard
  • Glossary and Notation
Loading lesson

‹Interview: FSM and Control
  1. Topics
  2. RTL Design
  3. Senior & Interview
  4. Senior RTL Interview Questions & Model Answers
  5. Interview: FSM and Control
  6. Choosing an FSM Encoding from Timing

Part 9 · Senior · Senior

Choosing an FSM Encoding from Timing

How STA results and platform pick binary, one-hot, or Gray codes, with an enum FSM and checks.

On this page

    Why this matters

    When the state decode sits on the critical path, "one-hot is faster" is a habit, not an answer. A routed one-hot net above 0.65 ns erases the margin in the worked case.

    After this lesson you can: choose between binary, one-hot and Gray from a timing report, let the tool re-encode an enum, and confirm the result afterwards.

    The question

    "Our STA report shows the FSM state decode on the critical path. Would you re-encode, and how?" The interviewer is testing whether the answer starts from evidence instead of habit.

    A strong answer names the options, ties each to a timing or area fact, and ends with how to confirm the fix in the report.

    Model answer

    Binary uses fewer flops but can need deeper decode. One-hot uses one flop per state and can simplify decode, at a routing and clock-load cost. Gray changes one bit only between adjacent entries in its chosen sequence; arbitrary FSM branches, aborts and resets need not follow that sequence.

    Use the platform and reports to compare candidates. For an arbitrary FSM status crossing, capture and hold a coherent status snapshot until the receiving handshake acknowledges it. Reserve Gray transfer for a constrained sequence whose every allowed transition is audited, with per-bit synchronization and physical bus-skew bounds; see encoding choice and bus crossing.

    Encoding

    Cost

    Choose it when

    Binary

    Few flops, wide next-state and output decode

    Small FSMs, area-tight logic, the tool default

    One-hot

    One flop per state, narrow decode, more routing

    FPGA targets, decode on the critical path, speed matters

    Gray

    One bit changes on each audited adjacent transition

    Constrained counters/sequences with synchronization and physical skew bounds

    Write the RTL as an enum and let the tool re-encode it through its FSM option. Confirm the result in the synthesis report, and re-run STA.

    Export decoded status rather than encoding-dependent bit tests. A default-to-IDLE specifies RTL behavior for unused codes; synthesis may re-encode or optimize that logic. If fault recovery is required, select supported safe-FSM controls, inspect extraction/encoding/recovery reports and check the implemented machine against the fault model. An enum alone does not guarantee safe implementation.

    Interview

    Compare mapped decode, routing and register cost under the latency contract; use a handshake for arbitrary status crossings and audit implementation recovery separately.

    Worked encoding decision

    Illustrative report inputs below are invented teaching budgets, not measured results. Assume five states, a 1.00 ns data-path budget after clock/setup terms, unchanged output latency, and room for two extra flops. Decompose total arrival before choosing.

    Candidate

    State flops / decode levels

    Cell + net arrival

    Decision evidence

    Binary

    3 / 3

    0.70 + 0.40 = 1.10 ns

    -0.10 ns: decode depth and shared output fanout need inspection

    One-hot

    5 / 1

    0.35 + 0.50 = 0.85 ns

    +0.15 ns: less decode, more route; inspect max fanout/slew and clock cost

    Binary + output register

    3 + output flops / split cone

    Separate stage budgets required

    Rejected here: adds output latency forbidden by the interface

    Under those illustrative budgets, try one-hot: it fits the flop allowance and preserves latency while recovering setup margin. Validate extracted encoding, all setup/hold views, route/fanout and power before accepting it. A routed one-hot net delay above 0.65 ns would erase this margin and reopen the choice. The transition bench below checks function, not this timing decision.

    Follow-ups

    • STA still fails after one-hot. What next? Register the FSM outputs or split the decode across a pipeline stage. Encoding is one lever among several.

    • Why not hand-write one-hot codes? Hand codes lock the encoding into the RTL. An enum keeps the logic unchanged while the tool tries each encoding.

    • The tool re-encoded the enum. How is that confirmed? Inspect the extracted FSM and final encoding in the synthesis report. The functional named-status checks can be reused if the status mapping is preserved; the internal forced-code injection must be rebuilt for the actual implementation encoding and fault model.

    Common wrong answers

    • "One-hot is always faster." On a tiny FSM the extra flops and routing cost more than the decode saves. The report decides, per FSM.

    • "Reset proves fault recovery." The default defines unused-code RTL behavior only. Supported safe-FSM controls and implemented fault-injection checks are needed for a recovery requirement.

    • "Gray fixes any state crossing." Branches and aborts can change multiple bits. An arbitrary state needs a stable snapshot handshake; an audited Gray sequence still needs synchronizers and physical bounds.

    Common pitfall

    Shared localparam state codes and bit tests such as if (state[1]) outside the FSM silently lock one encoding in. Compare against named enum values only, and expose decoded flags from the FSM instead.

    Check yourself Which fault model does forcing 5, 6 and 7 check?

    Only unused binary codes in this RTL encoding, with start low during recovery. It excludes a fault landing in another legal state, analog glitches, and synthesis re-encoding. The default specifies IDLE next; implementation recovery remains a separate obligation.

    Check yourself Which checks through state_o survive re-encoding?

    The functional state/status observations retain their meaning if the decoded mapping is preserved. The separate forced unused-code experiment targets internal RTL bits and is encoding-specific; it is not implementation fault coverage.

    Testbench

    The bench reaches five states, checks 20 state/input combinations, and injects unused codes 5–7. The named state_o mapping preserves the functional observations, but the internal fault injection is specific to this RTL encoding.

    burst_ctrl.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    // State codes are named once, above the design, so the testbench can reuse them.
    typedef enum logic [2:0] {IDLE, LOAD, RUN, WAIT, DONE} state_t;
    
    module burst_ctrl (
      input  logic       clk, rst_n, start, ready,
      output logic       active, done_o,
      output logic [2:0] state_o
    );
      state_t state, next_state;
    
      always_comb begin
        next_state = state;
        active = 1'b0;
        done_o = 1'b0;
        case (state)
          IDLE: if (start) next_state = LOAD;
          LOAD: begin next_state = RUN; active = 1'b1; end
          RUN:  begin active = 1'b1; if (ready) next_state = DONE; else next_state = WAIT; end
          WAIT: begin active = 1'b1; if (ready) next_state = DONE; else next_state = WAIT; end
          DONE: begin next_state = IDLE; done_o = 1'b1; end
          default: next_state = IDLE;
        endcase
      end
    
      always_ff @(posedge clk or negedge rst_n)
        if (!rst_n) state <= IDLE;
        else        state <= next_state;
    
      // Named-state readout for the testbench: literals only, so no enum-to-vector cast.
      always_comb begin
        case (state)
          IDLE: state_o = 3'd0;
          LOAD: state_o = 3'd1;
          RUN:  state_o = 3'd2;
          WAIT: state_o = 3'd3;
          DONE: state_o = 3'd4;
          default: state_o = 3'd7;
        endcase
      end
    endmodule
    

    Remember

    • Write the FSM as an enum and let synthesis re-encode it; confirm in the report and re-run STA.

    • Do not use bit tests such as state[1] outside the FSM; export decoded flags.

    • A default-to-IDLE only defines RTL behaviour; recovery needs safe-FSM controls and fault checks.

    Rule of thumb: the report decides the encoding, per FSM.

    How this was checked

    Bench run with Icarus Verilog 13.0 (2026-10-16): prints PASS. It reaches five states, checks 20 state/input combinations and injects unused codes 5 to 7. It does not establish post-synthesis fault recovery.

    The report numbers in the worked decision are invented teaching budgets, not measured results.

    Keep going

    • Practice: One-hot vs binary encoding trade-offs and pitfalls

    • Practice: Mixed encoding hazards when tools re-encode automatically

    • Code lab: One-hot control FSM

    • Interview: run a mock interview on this topic

    Related topics

    • Choosing an encoding

    • Illegal states and recovery

    Previous

    321 / 350

    Next: Moore vs Mealy Outputs

    Up next

    Up nextMoore vs Mealy Outputs

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Proving an FSM Correct
    • The Controller and Datapath Split