Verification architecture design
Components, data and control flow, interfaces, layering, and reuse.
- Design a UVM environment for an AXI interconnect with multiple masters and slaves.
- Design an environment for PCIe, cache, NoC, or DMA.
System verification strategy
Choose model fidelity and production infrastructure
Part 4 · Production practice
Recognize system-design prompts, state model tradeoffs explicitly, and add portability, causal trace, fault-campaign, and replay discipline.
Keep the source of truth, observation path, stress model, and exit evidence explicit so every verification decision can be reviewed.
Production practice3 focused sectionsNative diagrams + worked reasoning
Recognize the prompt
Five system-design question types.
Verification architecture, test strategy, infrastructure, HW/SW integration, and observability prompts reward different emphases.Test strategy and coverage
Testplan, coverage model, corner cases, and the balance between directed and constrained-random testing.
- How would you verify this protocol?
- How would you verify this microarchitecture?
Infrastructure and tooling
APIs, data models, scale, observability, and extensibility.
- Design a Python or C++ RTL memory framework.
- Design regression triage, log analysis, or a coverage dashboard.
Hybrid HW/SW system thinking
Top-level use cases, stimulus at multiple abstractions, firmware, and golden models.
- Verify an accelerator connected to CPU, DMA, and memory.
- Verify boot, mailbox, doorbell, and interrupt flows.
Debug and observability architecture
Where to observe causality and how to layer SVA, monitors, models, and debug evidence.
- Architect checking for a complex fabric.
- Choose signal taps, scoreboards, assertions, traces, and logs.
Model design choices
High fidelity is not automatically better.
Choose the smallest trustworthy oracle that exposes the risks in scope, then state what a leaner or richer model cannot prove.1 · Feature granularity
Feature-rich golden model versus Lean focused model
Feature-rich golden model
Aims to implement the complete specification.
Benefits
- Acts as a comprehensive verification oracle.
- Provides high confidence in DUT correctness.
Costs
- Needs extensive verification of its own.
- Has high development and maintenance cost.
Lean focused model
Implements only the features required by the test scope.
Benefits
- Easy to validate and trust.
- Fast to develop and maintain.
Costs
- Can miss subtle behavior outside its scope.
- Cannot serve as a universal oracle.
2 · Data structure
Object or dictionary model versus Flat byte array
Object or dictionary model
Uses associative arrays or objects per entry.
Benefits
- Efficient for sparse memory.
- Stores per-entry metadata such as dirty or state bits.
Costs
- Higher memory footprint and slower access.
- More complex to navigate during debug.
Flat byte array
Stores a compact contiguous value array.
Benefits
- Fast access and low overhead.
- Simple component interchange.
Costs
- Inefficient for sparse address spaces.
- Rigid and awkward for per-byte metadata.
3 · Timing accuracy
Cycle-accurate model versus Transaction-level model
Cycle-accurate model
Models queues, latency, resources, and per-cycle state.
Benefits
- Exposes timing hazards and backpressure bugs.
- Supports realistic performance prediction.
Costs
- Tightly coupled to simulation time.
- Complex, stateful, and slower.
Transaction-level model
Treats operations as atomic events.
Benefits
- Fast and simple.
- Portable across tests and projects.
Costs
- Misses timing-dependent bugs.
- Cannot model bottlenecks realistically.
4 · Integration style
Tightly coupled DPI-C versus Loosely coupled service
Tightly coupled DPI-C
Uses direct synchronous calls from UVM.
Benefits
- Low communication latency.
- Simple execution ordering.
Costs
- Difficult to reuse outside the simulator.
- Poor fit for offline replay and independent tooling.
Loosely coupled service
Uses sockets, standardized messages, or logs.
Benefits
- Model can run standalone.
- Enables offline debug, replay, and reuse in other tools.
Costs
- More infrastructure and communication latency.
- Needs protection against desynchronization.
Production-scale extensions
Four additions for production-scale verification.
These practices close common gaps between a technically sound block-level plan and a system program that remains portable, reproducible, and auditable.Scenario intent across engines
Keep the scenario graph above pin-level implementation so the same use case can target simulation, emulation, FPGA prototypes, and post-silicon—with engine-specific drivers and checkers.
- Portable Stimulus
- UVM virtual sequences
- Firmware tests
- Capability guards
Correlation IDs and causal traces
Give a transaction one identity from source request through routing, buffering, retry, completion, interrupt, and firmware acknowledgement. Preserve bounded trace history around failure.
- Accept/commit timestamps
- Config snapshots
- Credit snapshots
- Checkpoint + replay
Injection is only half the test
Cross fault type and injection point with detection mechanism, detection latency, containment boundary, software-visible status, recovery action, and post-recovery data integrity.
- Detected
- Contained
- Reported
- Recovered
Make every failure replayable
Record seed, binary, RTL build, topology, register programming, traffic constraints, clock and power schedules, injected faults, and reference-model version as one immutable run manifest.
- Run manifest
- Deterministic seed replay
- Minimal reproducer
- Failure clustering
Portable execution referenceAccellera's Portable Test and Stimulus Standard 3.0 defines a single scenario representation that can produce implementations for simulation, emulation, FPGA prototyping, and post-silicon execution.