No. 38 / project of 147 on the ladder

Official arch-test packaging

introduces — A single named DUT plugin and one make target that runs every scoped extension batch together

harden statelast run2026-05-03
areaunknownμm²
signoff
  • DRCNOT RUN
  • LVSNOT RUN
  • antennaNOT RUN

P38 keeps the P37 RV32IM + Zicsr + Zifencei core unchanged. The diff is administrative: the DUT plugin we have always been passing into the upstream riscv-arch-test framework moves into a named directory, and one make arch_test target now runs all four scoped batches together and writes a single aggregated SWEEP.md.

Status: RTL pass. No P38 harden run is recorded yet. The arch-test sweep is wired up but the recorded SWEEP.md is NOT RUN until the user runs it.

What was already true

We were never running a homegrown test pile. Since P15 the harness has been generating self-checking ELFs through the upstream act flow against the upstream riscv-arch-test repo, with Sail as the reference. The DUT-specific contract - halt convention, memory map, tohost/fromhost section - lived under projects/26_rv32i_act4_probe/act4/ and was passed in via --act4-dir on every batch invocation.

P38 puts that plugin where it belongs. See the arch-test page for the framework-side mental model.

What changed

changewhy
arch_test/rvmodel_macros.h + link.ldone canonical plugin location
make arch_test aggregate targetone entry, four batches, one SWEEP.md
scripts/p38_arch_test_sweep.pyreads four RESULTS.md, writes one SWEEP.md
test/tb_arch_test.svfuture signature-dump testbench, built via make sigbench, not used by the default flow

Nothing in src/top.sv differs from P37 except CSR_MIMPID reading 0x0000_0038. No new instructions, no new traps, no new MMIO, no new clocking.

Expected sweep

suiteexpected
ACT4/Sail rv32i/IPASS=39 FAIL=0 NOT RUN=0
ACT4/Sail rv32i/MPASS=8 FAIL=0 NOT RUN=0
ACT4/Sail rv32i/ZicsrPASS=6 FAIL=0 NOT RUN=0
ACT4/Sail rv32i/ZifenceiPASS=1 FAIL=0 NOT RUN=0
AggregatePASS=54 FAIL=0 NOT RUN=0

That is the same set of PASSes P37 reported. The point of P38 is that they are now reported through one named flow against one named DUT plugin.

Future infrastructure

tb_arch_test.sv is the start of a canonical signature-flow path: each test writes its signature region during execution, the testbench dumps that region at halt, and an external comparator diffs the dump against *.reference_output. Useful for tests where the in-ELF self-check is not available (e.g. multi-phase tests). Not used by P38 itself; the P39 (Zicntr) rung is the natural place to wire it up.

What just happened?

P38 does not change what the chip can do. It changes who the chip appears to be - a DUT with a properly-organised plugin under the upstream framework, rather than a CPU dragging four --act4-dir arguments around. That is enough to clean up the framing on the site and let the next rung start from a tidier base.