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

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • Meet DCRouter
  • Glossary
  • Part 0: What Verification Is8
  • Part 1: What Can Go Wrong11
  • Part 2: Specifications as Checkable Rules8
  • Part 3: Observability and Controllability7
    • Controllability
    • Observability
    • Bug Propagation and Masking
    • Black Box, White Box, Grey Box
    • Hooks and Test Modes
    • Design for Verification
    • Drills: Observability and Controllability
  • Part 4: Stimulus11
  • Part 5: Checking11
  • Part 6: Coverage10
  • Part 7: Formal and Simulation10
  • Part 8: Verification Levels and Reuse8
  • Part 9: Planning and Risk9
  • Part 10: Emulation and Prototyping8
  • Part 11: Post-Silicon Validation8
  • Part 12: Bug Economics8
  • Part 13: Debug7
  • Part 14: Sign-Off7
  • Part 15: Verification in Context8
  • Part 16: Case Studies5
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 3: Observability and Controllability
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 3: Observability and Controllability
  4. Controllability

Part 3 · Observability and Controllability · Working (W)

Controllability

A test can only find a bug in a state it can reach. Controllability is how easily the testbench can drive the design into the states that matter; deep, rare or timing-dependent states are hard to reach from the pins. DCRouter's hard-to-reach states, what it takes to reach each, and the ways teams make them reachable.

On this page

    Note

    Level: Working (W) · Answers: Can we see and steer what matters?

    Before this: Part 3 overview, You Cannot Test Everything

    DCRouter's error counter saturates at 255. To check that it saturates rather than wraps, a test must first put 255 errors into it, each one a whole packet with a bad CRC sent through the router. A state that one line of RTL describes takes the testbench hundreds of packets to reach. Some states are harder still: sleeping while an output is locked mid-packet needs one source to pause for eight cycles in the middle of a packet while every other port is silent.

    How easily can the testbench put the design into the state a check needs?

    The obvious answer, and why it breaks

    The obvious view is that the testbench drives every input, so it controls everything. It controls the inputs. The state that matters is often several steps away: a full FIFO needs a stalled output behind it; a credit at zero needs a sink that stops returning credits; a saturated counter needs 255 events. Each step must be caused through the pins, in order, while other activity does not undo it. A random test that never happens to line the steps up never reaches the state, and no check there can fire.

    The idea: distance from the pins

    Controllability is the ease of reaching a state from the inputs: how many steps, how specific, and how fragile. A useful habit is to estimate, for each important state, what sequence reaches it.

    Near states take one packet; deep states need a sequence of conditions held in order, and are rarely reached by chance.

    DCRouter's hard states

    State

    What reaches it

    Why it is hard

    Input FIFO full (R1)

    Fill an input faster than its output drains: stall the sink or contend for the output

    Fast sinks and free outputs drain the FIFO first

    Credits at zero (R7)

    A sink that stops returning credits while 4 flits are sent

    Needs the sink to misbehave on purpose

    Two tails in one cycle (R10)

    Packets on two outputs ending in the same cycle

    Timing coincidence; depends on lengths and arbitration

    ERR_CNT at 255 (R9)

    255 faulty packets on one input

    Long; at 5% faults that is about 5,100 packets

    Asleep with an output locked (R13)

    A source pausing 8 cycles mid-packet while all else is idle

    Every other port must be silent at the same time

    Woken by port 3 alone (R13)

    Sleep, then traffic on input 3 only

    Random traffic usually wakes it from another port first

    Every one of these states hides a Bug Zoo bug (1, 10 and 9, 11, 15, 20, 21). A test that cannot reach the state cannot find the bug, however good its checks.

    What reduces controllability

    • Depth: states that need long sequences (counters, deep FIFOs, timers).

    • Coincidence: states that need several things in the same cycle (simultaneous tails, a credit return during a send).

    • Quiet: states that need everything else to stop (sleep, idle timeouts).

    • Fixed configuration: states only reachable in a mode the test never selects (a disabled port, priority off).

    • Undriven interfaces: neighbours modelled too politely to ever stall, error or reorder (lesson 1.5).

    Ways to make a state reachable

    Technique

    How it helps

    Where in the course

    Directed sequences

    Construct the steps on purpose

    Lesson 4.1

    Biased and constrained random

    Make the conditions common instead of rare

    Lessons 4.4, 4.5

    Aggressive environment models

    Sinks that stall, sources that pause

    Lesson 4.8

    Backdoors and test modes

    Set deep state directly, or shorten timers

    Lesson 3.5

    Smaller configurations

    Shallower FIFOs and counters make limits close

    Lesson 3.6

    Formal

    Considers every reachable state without constructing sequences

    Part 7

    How real teams handle it

    Practice

    Purpose

    List hard-to-reach states in the verification plan

    Each gets a strategy, not hope

    Coverage points on those states

    Shows whether the regression ever reached them (Part 6)

    Ask designers for controllability features

    Configurable depths and timers, test modes (lesson 3.6)

    What breaks

    In lesson 4.10, DCRouter's constrained-random hunt runs 274 packets with 5% faults and never reaches ERR_CNT = 255, so it misses BUG_15 (the counter wraps). The error-injection test of lesson 4.7 reaches the state in one directed loop of 300 faulty packets and catches it. The check (compare ERR_CNT with the faults injected) was the same; only controllability differed.

    Why this matters

    Senior lens. For every rule, ask what state the check needs and what sequence reaches it. If the honest answer is "random will probably get there", estimate the probability (lesson 4.5); if it is small, plan a directed path, a bias, a test mode or a proof. Unreached states are where confident regressions hide bugs.

    Interview

    Asked: "Why is a deep FIFO-full state hard to reach?"

    Weak answer: Because random tests don't send enough data.

    Strong answer: Because it isn't controlled directly: the FIFO only fills when the input runs faster than the output drains, which needs the downstream side to stall or another input to win the output for long enough, and nothing else to drain it meanwhile. That's a sequence of conditions held in order, and well-behaved sinks never create it. I'd reach it on purpose: an environment that stalls credits, contention on one output, or a smaller FIFO configuration, and I'd put a coverage point on full so I know it happened.

    Follow-ups: (1) How would you reach a counter's saturation value quickly? (2) What makes a state hard to reach besides depth?

    Check yourself Why does a fast, always-ready sink make DCRouter's FIFO-full state unreachable from a single input?

    The FIFO drains as fast as it fills (one flit per cycle in and out), so occupancy never builds up; filling it needs the output to stall or be taken by another input.

    Check yourself Name the controllability problem in "woken by port 3 alone".

    Quiet plus coincidence: everything must be idle long enough to sleep, and then only input 3 may become active; random traffic usually wakes it from another port.

    Key takeaways

    • A check can only fire in a state the test reaches.

    • Depth, coincidence, quiet and fixed configuration make states hard to reach.

    • Reach hard states on purpose: directed paths, bias, aggressive models, test modes, smaller configurations or formal.

    Keep going

    Next: Lesson 3.2, Observability. Reaching the state is half the job; the wrong value must also be seen.

    Related topics

    • Part 3 overview: Observability and Controllability

    Previous

    33 / 160

    Next: Observability

    Up next

    Up nextObservability

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Bug Propagation and Masking
    • Black Box, White Box, Grey Box
    • Hooks and Test Modes