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. Drills: Observability and Controllability

Part 3 · Observability and Controllability · All levels

Drills: Observability and Controllability

Interview questions, a whiteboard exercise and a ten-question checkpoint for Part 3.

On this page

    Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.

    Interview questions

    Check yourself What is controllability?

    How easily the testbench can drive the design into the state a check needs; depth, coincidence, quiet and fixed configuration reduce it.

    Check yourself What is observability?

    How easily a wrong internal value becomes visible to a check: whether it reaches an output, how soon, and how clearly it points to the cause.

    Check yourself Your test hit the bug but passed. How?

    Activation is not enough: the wrong value was masked before an observed point, or reached an output no check compared.

    Check yourself Should checkers look inside the design?

    Selectively: black-box scoreboards end to end, grey-box checks at stable internal boundaries, designer-owned internal assertions, and never an expected value taken from the design itself.

    Check yourself When is a backdoor access a bad idea?

    When it replaces the behaviour under test; use it for setup and keep a frontdoor test for every path it skips.

    Check yourself What would you ask a designer to add?

    Status visibility for hidden state, parameterised depths and timers, designer assertions, clean interfaces, deterministic reset, debug counters.

    Whiteboard exercise

    Task. A DMA engine has a 64-entry descriptor queue, a 16-bit idle timeout, an internal retry counter (up to 7 retries per transfer) and a completion interrupt. For each of these four, say how hard it is to reach and to observe from the pins, and what you would do about it.

    Check yourself Open a model answer

    Descriptor queue: reaching full needs 64 descriptors queued while the engine is stalled; observable only as refused writes. Ask for a depth parameter and an occupancy status field; drive a stalled memory model; cover full. Idle timeout: 65,535 idle cycles is slow to reach; ask for a programmable threshold, test it short, and test the full value once or prove it with formal. Retry counter: reaching 7 retries needs a memory model that errors repeatedly on one transfer; the count is hidden, visible only as a final error. Use error injection to force retries, ask for the retry count in a status register, and add a designer assertion that it never exceeds 7. Completion interrupt: easy to reach, but a missed or duplicated interrupt is visible only if every interrupt is matched to a transfer; check interrupts against completed descriptors and read the interrupt status at the end of each test.

    Checkpoint: ten questions

    Check yourself 1. Which DCRouter state needs every port silent at once?

    Sleeping (and sleeping with an output locked mid-packet).

    Check yourself 2. How many faulty packets does it take to reach ERR_CNT = 255 at a 5% fault rate?

    About 5,100 on one input.

    Check yourself 3. Why does BUG_9 pass a per-flit scoreboard?

    Losing credits only slows the output; no flit is wrong.

    Check yourself 4. How does a credit audit expose lost credits?

    With the sink stalled, exactly 4 flits must leave each output; fewer means credits were lost.

    Check yourself 5. Name the three conditions for a test to catch a bug.

    Activation, propagation, detection.

    Check yourself 6. In the masked-adder example, why did test A pass?

    mode was 0, so the mux selected a and the wrong sum never reached y.

    Check yourself 7. Why did the first grey-box FIFO checker fail to catch BUG_1?

    It used the FIFO's own full flag, which is where the bug was; the fixed checker keeps its own occupancy count.

    Check yourself 8. What is the safe pattern for backdoor access?

    Backdoor to set up, frontdoor for the behaviour under check, and a frontdoor test for every path the backdoor skips.

    Check yourself 9. What does a shortened-timer test mode leave unverified?

    The shipped timer length, its comparison logic and the mode-select logic.

    Check yourself 10. Why ask for design-for-verification features at specification review?

    They cost an afternoon then and a change request after RTL freeze, and their savings repeat in every test.

    Revisit

    • 3.1 Controllability

    • 3.2 Observability

    • 3.3 Bug Propagation and Masking

    • 3.4 Black Box, White Box, Grey Box

    • 3.5 Hooks and Test Modes

    • 3.6 Design for Verification

    Keep going

    Next: Part 4: Stimulus. How do we drive the design into the states that matter?

    Previous

    39 / 160

    Next: Part 4: Stimulus

    Up next

    Up nextPart 4: Stimulus

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Controllability
    • Observability
    • Bug Propagation and Masking