- 1. Introduction
- 2. Test bench setup and deterministic sequences
- 3. Implemenation parameters needed by the testbench
- 4. Test sequences
- 4.1. suite of tests to verify interrupt privilege result
- 4.2. suite of tests to verify interrupt priority encoder implementation
- 4.3. hardware vectoring test
- 4.4. verify clicinfo csr matches build parameters
- 4.5. check clicintattr/ctrl/ip/ie accessibility in s-mode, u-mode
- 4.6. verify xcause mstatus bits match xstatus
- 4.7. verify xnxti
- 4.8. verify xintthresh
- 4.9. verify preemption works without losing state
- 4.10. verify WFI cases
- 4.11. verify clicintie masking works
- 4.12. verify mclicbase matches CLICCFG implementation parameter
- 4.13. verify xideleg and xedeleg still accessible but have no effect in clic mode
- 4.14. check XIE, XIP CSRs appear hardwired 0 in CLIC mode,
- 4.15. verify only mtvec, not stvec or utvec can change from clic to non-clic mode
- 4.16. byte write of clicintip/ie/ctl/attr vs. 32-bit write
- 5. Coverage Holes
A plan for developing the riscv architectural tests for the Fast Interrupt Extension.
The point of this test plan is to:
-
Explain what the RISC-V architectural tests try to achieve, both generally and for the fast interrupt architecture in particular.
-
Act as a starting point for verification engineers writing verification plans.
Some useful links:
The framework for architectural tests is to load a test (binary) and start a hart, the hart signals finished, results are extraced from memory and verified against a signature. Since interrupts can occur asynchronously it is limiting to create deterministic tests for different implementations with results that can be compared with SAIL model results. For example, with different implementation, a different number of instructions will occur before the pending interrupt bit actually gets set. Depending on the implementation, the execution pc could be a different value than the SAIL model.
-
if implementation only has level interrupts (pending bit cannot be set by testbench), testbench sets interrupts to the asserted position before running the test. Since mstatus.mie is reset by default, no interrupts will be taken until it is enabled.
-
setup cliccfg
-
setup xthresh
-
setup interrupt based on implementation parameter
-
setup xtvec_handler
-
fence instruction
-
enable status.mie/sie/uie
-
loop to self
This sequence ensures the xepc value will be the loop to self and implementation signatures should match SAIL model.
-
EDGE: 0 - level, 1 - edge. If set to 0, testbench will need to assert the interrput before the test binary is run.
-
NEG: 0 - positive, 1 - negative (interrupt polarity, only used if testbench is level and will be asserting interrupts before test binary is run.
-
INTERRUPT1_NUM - 1st interrupt number, used to calculate interrupt address and expected exccode value.
-
INTERRUPT2_NUM - 2nd interrupt number for tests that require 2 interrupts (preemption, priority encoder verification)
-
CLICCFG - address of cliccfg register. Used as base address for interrupt address calculation and verification of mclicbase value.
-
CLICINTCTLBITS - number of implemented clicintctl bits.
-
addresses of new CLIC csr registers. Until the spec is ratified, the implementation will need to provide the addresses of the new CLIC csr registers for that implementation.
-
based on CLICINTCTLBITS, nlbits, clicintctl[i] setting for m, m/u, m/s/u implementations
-
compare against table in section 3.2.1 Specifying Interrupt Privilege Mode
-
compare against table in section 7.1 General Interrupt Overview
-
checks xtvt
-
create a pmp violation to check xinhv? if fault xtval and xepc tested
-
in non-clic mode a read should return 0
-
in interrupt routine, check xnxti when interrupt pending and when not pending to verify conditional behavior
-
interrupt chaining
-
retain value when switched back to original mode