At principal level the question is often a single line: "plan the verification of an interconnect", "of a cache", "of an accelerator". There is no right answer to memorise. What interviewers judge is whether your answer has a structure, starts from risk, knows where the oracle comes from, and ends with a decision about when you are done.
Step | What to cover |
|---|---|
1. Clarify | Ask about interfaces, configurations, performance targets, what is reused, the schedule and the consequence of a bug. |
2. Risks | Name the three or four things most likely to go wrong, and why. |
3. Oracle | Where the right answer comes from: reference model, ISS, golden model, properties. |
4. Methods per risk | Directed, random with a scoreboard, formal, emulation, each assigned to risks with a reason. |
5. Levels | Block, subsystem, SoC, software; what is verified where. |
6. Measures | Coverage model, planted bugs, bug trend with effort. |
7. Done | Sign-off criteria and the residual risk you would state. |
Spend the first minute on step 1. Clarifying questions show that you know the answer depends on them, and they give you the constraints for every later step. Then go through the steps briefly, and expand wherever the interviewer probes.
Step | Answer |
|---|---|
Clarify | How many managers and subordinates? Outstanding transactions, IDs, QoS? Address map fixed or programmable? Configurable IP or one instance? |
Risks | Routing and decode errors; ordering per ID; deadlock under contention; protocol violations at boundaries (bursts that must not cross a 4 KB boundary, narrow transfers); arbitration starvation. |
Oracle | A transaction-level model of the address map and routing; protocol rules from standard VIP assertions; ordering rules per ID. |
Methods | Standard VIP for each port with protocol checks; constrained-random traffic with a scoreboard keyed by ID; formal on the decoder and arbiter; directed tests for decode boundaries; long random runs for deadlock with a watchdog. |
Levels | Interconnect in isolation with VIP; SoC level for connectivity (formal connectivity checks) and real traffic patterns. |
Measures | Coverage of every manager-subordinate pair, ID reuse, outstanding depth, burst types and boundaries; planted routing and ordering bugs. |
Done | Every pair and ordering rule evidenced, protocol checks clean on all ports, arbiter properties proved, no deadlock in N billion cycles; residual risk: unmodelled traffic mixes, configurations not built. |
Step | Answer |
|---|---|
Clarify | Write-back or write-through? Coherence protocol and number of agents? Replacement policy? Error correction? |
Risks | Coherence violations (stale data); races between a fill and an eviction or snoop; replacement corner cases; data loss on write-back. |
Oracle | A memory model that knows the value every address should hold (a shadow memory) checked on every read; coherence invariants as properties (single writer, multiple readers). |
Methods | Random traffic from several agents concentrated on few addresses to force conflicts; formal on the coherence state machine and its invariants; directed tests for races; error injection on ECC. |
Levels | Controller with agent models; multi-core subsystem with real cores running litmus tests for the memory model; SoC level with software. |
Measures | Coverage of every state and transition of the protocol, every race pair, set conflicts; planted coherence bugs. |
Done | Coherence invariants proved or exhaustively checked on a small configuration, shadow-memory checks clean on long runs, litmus tests passing; residual risk: configurations larger than proved. |
Step | Answer |
|---|---|
Clarify | Fixed-point or floating-point? Which kernels? Tiling and memory interface? Compiler-generated schedules? |
Risks | Tiling and addressing bugs (dropped, repeated or misaligned pixels); precision loss; edge handling (image borders); stalls under memory back-pressure. |
Oracle | A bit-accurate model of the datapath for exact comparison; a high-precision golden model with derived tolerances for the arithmetic choices. |
Methods | Bit-exact unit checks (formal for arithmetic units); random image sizes and strides with a bit-accurate scoreboard; real images and synthetic edge cases; emulation for full frames and the compiler's schedules. |
Levels | Units, then kernels, then the accelerator with its memory system, then software end to end. |
Measures | Coverage of sizes, strides, borders, tile boundaries, saturation; planted addressing bugs to validate tolerances. |
Done | Bit-exact against the bit-accurate model across the coverage space, accuracy targets met on real workloads; residual risk: untested compiler schedules. |
Clarifying questions first, not a recited methodology.
Risks specific to the design: coherence for a cache, ordering for an interconnect, addressing for an accelerator.
An oracle for each risk, and an honest answer where none is easy.
Methods assigned with reasons, including where formal fits and where it does not.
A definition of done with residual risk, not "100% coverage".
Clarify: protocol generation, ranks, ECC, low-power modes, PHY ownership. Risks: command timing violations, refresh starvation, reordering and data integrity, ECC, power-down entry and exit with traffic. Oracle: memory model with timing checks (standard VIP), shadow memory for data. Methods: VIP-driven random traffic, timing assertions, formal on the scheduler and refresh counter, error injection for ECC, power transitions mid-traffic. Done: timing checks clean, data checks clean across modes, scheduler properties proved; residual risk: PHY and electrical behaviour owned by the PHY team.
Clarify: ASIL target, baud rates, FIFO depths, error detection required. Risks: framing and parity errors, baud-rate edge cases, FIFO overflow, and undetected hardware faults. Oracle: a reference model of the serial protocol. Methods: directed and random serial streams with error injection; formal on the FIFO and state machine; fault injection to measure diagnostic coverage of the safety mechanisms. Done: functional evidence plus measured SPFM and LFM against the ASIL targets, traceability for the assessor.
Clarify: ISA extensions, privilege modes, pipeline depth, caches, interrupts. Risks: hazards and forwarding, exceptions and interrupts, privilege transitions, memory ordering. Oracle: an ISS in lock-step. Methods: random instruction generators biased to hazards, compliance suites, formal on the pipeline, OS boot on emulation. Done: compliance passing, lock-step clean over a large random corpus with coverage of hazards and exceptions; residual risk: microarchitectural side channels unless specified.
Start with clarifying questions; they set every later decision.
Make the risks specific to the design, with an oracle and a method for each.
End with a definition of done and the residual risk.