Overview
TestRIG is presented in the paper Randomized Testing of RISC-V CPUs using Direct Instruction Injection as a RISC-V testing framework centered on open implementations, RVFI-DII-compatible components, and verification engines. The authors state that current TestRIG-compatible implementations and verification engines have been collated into an open-source TestRIG repository with documentation, and they expect TestRIG to contribute toward a standardized RISC-V testing framework that uses instrumentation of open implementations.
Verification approach
The evidence describes TestRIG in terms of model-based randomized testing and direct instruction injection. QCVEngine is identified as the initial TestRIG verification engine. Its Haskell infrastructure supports rich and complex generators, although the paper notes that its generators for virtual memory, cache testing, and floating-point operations were still rudimentary and could be improved with more intelligent directed-random templates.
TestRIG-compatible systems support RVFI-DII, and future memory-model testing is described as injecting RVFI-DII instruction streams with specified timestamps into multiple shared-memory cores. The same discussion states that a more advanced verification engine would need to test RVFI traces not only for equivalence, but also against higher-level memory-model semantics.
Counterexample-driven development
The paper describes TestRIG's model-based testing as leading to counterexample-driven development. In contrast to conventional test-driven development for processor design, which the authors say requires a basic working design before architectural unit tests can be used, TestRIG can automatically provide reduced stimulus for both basic features and advanced interactions.
The CHERI extension to Ibex is given as an example: after Ibex was extended with RVFI-DII support, a summer intern was able to independently add full CHERI functionality to Ibex in a month, attributed to the tight cycle of reduced counterexamples provided by QCVEngine.
Debugging example
The evidence includes a Flute processor bug found by a TestRIG generator that constructed addresses within the TestRIG memory range together with random loads and stores. The generator discovered the bug after 42 tests and 20 rounds of shrinking. The final reduced sequence contained three memory operations: two loads with a store between them, all to overlapping addresses. The counterexample was found less than 10 seconds into the TestRIG run and was fixed within the hour. The authors state that the bug had escaped the Flute development process, was not found by the RISC-V unit-test suite, and was difficult to debug from a full software trace.
Relationship to architectural models
The evidence discusses prior CHERI work using formal ISA models and constraint solving to generate instruction sequences, and notes ongoing work on a Sail-OCaml VEngine with direct access to Sail RISC-V model data structures. The stated motivation is to eliminate independent encodings in the VEngine and potentially automate template generation for reaching deep architectural states.
Future directions
The paper identifies several future TestRIG directions: improving QCVEngine generators for virtual memory, cache testing, and floating-point operations; supporting memory-concurrency testing; and checking RVFI traces against higher-level memory-model semantics rather than only equivalence. The conclusion frames TestRIG as a cohesive community of verification tools that improves on traditional instruction-set-level unit testing and subsumes specialized random test generators.