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
      • Why scan exists
      • The scan chain at RTL abstraction
      • Test-mode integration checklist
      • Controllability and observability in practice
      • Fault Coverage by Hand
    • 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
  • Glossary and Notation
Loading lesson

‹DFT and Scan Hub
  1. Topics
  2. RTL Design
  3. Senior & Interview
  4. DFT and Scan Hub
  5. Why scan exists

Part 9 · Senior · Senior

Why scan exists

Functional patterns cannot reach deep state; scan turns every flop into a controllable, observable point.

On this page

    Why this matters

    Reaching state 15 of a 4-bit counter takes 15 clock edges, and the count grows exponentially with width, so deep faults stay hidden. Scan loads that state directly in 4 edges.

    After this lesson you can: explain why scan gives access to deep state, name what ATPG needs from the RTL, and say when scan does not help.

    Deep state hides faults

    Without scan, many faults remain hidden because functional paths are too deep or require impractical input sequences.

    A 4-bit counter stands in for that depth. Reaching state 15 from reset takes 15 clock edges functionally, and the count grows exponentially with state width.

    What ATPG needs from RTL

    Automatic test-pattern generation treats each capture cycle as combinational logic between scan flops. Three properties make that work.

    Property

    Question it answers

    RTL consequence

    Controllability

    Can the tool drive an internal node to 0 and 1?

    Every flop reachable from scan-in

    Observability

    Can a node effect reach scan-out or a primary output?

    Key nodes captured into scan-visible flops

    Deterministic test mode

    Are clocks, resets, and constraints predictable while shifting?

    The integration checklist in the next lessons

    Four mux-D scan flops chained from SI to SO, with n = q1 & q0 feeding q3, and the 15 functional edges against 4 shift edges to reach state 15

    Read the chain left to right: the coloured wire is the scan path and the dark wires are functional logic.

    • Each flop has a mux in front of it. scan_en = 1 takes the previous flop, scan_en = 0 takes the functional input.

    • Shifting in 0,0,1,1 puts the first bit in q3, so the chain reads q3 q2 q1 q0 = 0 0 1 1.

    • The capture edge loads n = q1 & q0 = 1 into q3. Shifting out then shows q3 first.

    • The lower panel counts edges: 15 to count up to state 15, 4 to load it directly.

    With scan and without it

    Worked fault destination: the four-flop chain below uses q0-to-q3 serial order. Load 0011, activate a stuck-at-0 defect on n = q[1] & q[0], capture n into q[3], then read q[3] first. The parallel-load counter remains an access stand-in; the next lesson adds this fault experiment to the serial chain.

    Scan does not change the functional design. It adds a second way to reach the same state.

    Task

    Without scan

    With scan

    Reach a deep state

    Run a long functional sequence

    Shift the state in directly

    Observe a deep node

    Propagate its effect to a pin

    Capture it and shift it out

    Generate patterns

    Sequential search over many cycles

    Combinational search per capture cycle

    Common pitfall

    Scan improves access, not coverage by itself. Untestable logic (redundant, tied-off, or unconstrained paths) stays untestable until the RTL gives the tool a path to it.

    Interview

    Likely follow-up: “when does scan not help”. Name untestable logic, asynchronous paths the tool cannot clock, and analog or X-source boundaries that need masking first.

    Check yourself A block has 20 flops and no scan. What makes its sequential depth a test problem?

    Reaching any one of a million states can need a long, exact input sequence. The tool must search cycle by cycle instead of loading the state directly.

    Check yourself Scan is inserted and coverage is still low. What is the first suspect?

    Untestable or unconstrained logic, not the chain. Check tied-off modes, undriven inputs, and X sources before suspecting the stitching.

    Testbench

    A 4-bit counter with a parallel load stands in for scan access. The testbench counts functionally, then loads directly.

    deep_state.sv
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    `timescale 1ns/1ps
    module deep_state (
      input  logic       clk,
      input  logic       rst_n,
      input  logic       load_i,
      input  logic [3:0] load_val_i,
      output logic [3:0] q_o
    );
      always_ff @(posedge clk or negedge rst_n) begin
        if (!rst_n)      q_o <= 4'd0;
        else if (load_i) q_o <= load_val_i;
        else             q_o <= q_o + 4'd1;
      end
    endmodule
    

    Remember

    • A scan flop has a mux in front: scan_en = 1 takes the previous flop, scan_en = 0 takes the functional input.

    • ATPG treats each capture cycle as combinational logic between scan flops.

    • Scan improves access, not coverage. Untestable logic stays untestable until the RTL gives the tool a path to it.

    Rule of thumb: scan adds a second way to reach the same state; it does not change the function.

    Keep going

    • Code lab: Scan chain stub

    • Interview: run a mock interview on this topic

    Related topics

    • The scan chain at RTL abstraction

    Previous

    278 / 350

    Next: The scan chain at RTL abstraction

    Up next

    Up nextThe scan chain at RTL abstraction

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Test-mode integration checklist
    • Controllability and observability in practice
    • Fault Coverage by Hand