Overview

Ibex Core is an open-source 32-bit RISC-V CPU core written in SystemVerilog and maintained by lowRISC. The provided thesis evidence describes it as production-quality, heavily parameterizable, suited for embedded control applications, and having undergone extensive verification and multiple tape-outs. The public lowRISC GitHub repository describes Ibex as a small 32-bit RISC-V CPU core, previously known as zero-riscy.

Ibex supports the RISC-V Integer (I) or Embedded (E) base, Integer Multiplication and Division (M), Compressed (C), and Bit Manipulation (B) extensions. The evidence also identifies Ibex as being used in OpenTitan, an open-source silicon Root of Trust project.

Verification approach

Ibex is verified with a UVM-based testbench that uses co-simulation to cross-check execution against a golden instruction-set simulator reference model, Spike. The testbench runs binaries built from source generated by the RISC-DV random instruction generator, stimulates the core to execute programs stored in memory, and compares the core trace log against the Spike trace log.

The verification environment collects coverage information for executed instructions and operands. It uses a test plan and coverage plan to cover relevant instructions and operations. Additional randomized stimulus includes memory timings, memory errors, interrupts, and debug requests.

Testbench components

The Ibex UVM testbench includes several named components:

• Memory interface agents: two instances are used, one for instruction fetch and one for the LSU interface. These agents run slave sequences that wait for memory requests from the core and grant requests for instructions or data.
• Interrupt agent: drives randomized stimulus onto the Ibex core interrupt pins during test execution.
• Memory model: a single memory model is loaded with the compiled assembly test program at the beginning of each test. It acts as a unified instruction/data memory serving requests from both memory interface agents.
• Test and sequence library: tests are extended from core-ibex-base-test and coordinate a full test flow, including loading the compiled binary into the memory model, checking core status, and handling timeouts. Sequences drive interrupt and debug stimulus into the core.

Co-simulation and RVFI

The co-simulation system can run in the Ibex UVM DV environment or with Simple System. It runs a RISC-V ISS in lockstep with an Ibex core; the evidence states that Spike is currently the supported ISS. Instructions executed by Ibex and generated memory transactions are checked against the ISS behavior.

The co-simulation system supports memory errors, interrupt requests, and debug requests by observing them in RTL simulation and forwarding them to the ISS to keep the ISS and RTL synchronized. The system uses a generic interface intended to allow multiple ISSes, although the cited evidence states that only Spike is currently supported. It also states that only VCS is supported as a simulator, while noting that no VCS-specific functionality is required, so adding another simulator should be straightforward. The RISC-V Formal Interface (RVFI) is used to provide information about retired instructions and instructions that produce synchronous traps for checking.

Verification scope and maturity

The Ibex parameter space is large enough that fully verifying every possible parameter set is impractical. Verification regressions and closure therefore target a set of supported configurations. The cited evidence states that verification closure is focused on the OpenTitan configuration, which is the only configuration with nightly regression runs in that context. Verification maturity is tracked with OpenTitan-defined Verification Stages. The evidence reports that 90% code and functional coverage had been achieved, with over a 90% regression pass rate, and that the test plan and coverage plan were fully implemented but not yet closed.