A custom RISC-V extension changes more than an arithmetic datapath. It consumes encoding space, updates architectural state, interacts with privilege and exceptions, and passes through a pipeline that must preserve hazards, forwarding, flushes, and retirement. Verification should begin with an extension specification precise enough to implement twice.
Define the architectural contract
Specify instruction encoding, operand interpretation, result width, signedness, rounding or saturation behavior, side effects, exceptions, privilege requirements, and behavior when the extension is disabled. State whether instructions are restartable and how they interact with interrupts, debug, and virtual memory where relevant.
Encoding verification includes negative space. Reserved and neighboring encodings must retain their specified illegal-instruction behavior. Parameterized implementations must not accidentally enable an extension or CSR when a configuration says it is absent.
Build an independent reference
The architectural predictor should be derived from the extension specification, not copied from RTL expressions. It can be integrated into an instruction-set simulator, a co-simulation adapter, or a transaction-level model. Compare architectural state at a defined commit point so pipeline timing does not leak into architectural checking.
- Directed tests: boundary values, each encoding, each exception, and each documented mode.
- Generated instruction streams: dependencies, hazards, control-flow interaction, and mixed standard/custom sequences.
- Differential checking: retirement state compared with an independent model.
- Assertions: decode exclusivity, issue rules, flush behavior, and retirement accounting.
- Formal targets: illegal encodings, bounded instruction semantics, and small control invariants.
Exercise privilege and interruption
Test execution at every permitted and forbidden privilege level. Check trap behavior defined by the implementation contract. Interrupts, debug entry, exceptions, and branch misprediction should not allow a killed instruction to update architectural state or a retiring instruction to disappear.
If the extension uses CSRs, verify address legality, reset values, access permissions, write masks, side effects, and interactions with context switches. Software-visible discovery mechanisms should agree with the implemented configuration.
Close microarchitecture separately
Architectural comparison can pass while performance or pipeline rules are wrong. Verify forwarding, stalls, multi-cycle occupancy, structural hazards, replay, and resource arbitration. Ensure custom operations cannot bypass security or memory-ordering controls applied to standard instructions.
An extension is compatible only when its defined behavior and the surrounding base architecture both remain correct.
Release evidence should include the specification revision, encoding table, reference-model revision, architectural tests, implementation-specific tests, coverage review, and known limitations. The RISC-V architectural test framework is useful input, but a custom extension still requires its own normative test plan.
Primary references
Need help applying these methods to a verification programme? Start a technical conversation.