Today we tried the official RISC-V architectural tests against P14, mostly to see where the floor actually is.
First result: the local P14 ISA smoke addendum still passes. That is
our tiny chip-pin-side suite: boot from SPI flash, run a short program,
halt, and check R5[4:0] on uo_out[7:3].
Then we pulled a sparse copy of upstream riscv-arch-test into
/tmp/riscv-arch-test and built the official RV32I/I unprivileged
integer tests with the local riscv64-elf-* toolchain.
Probe command:
scripts/p14_arch_test_probe.pyResult:
| item | result |
|---|---|
| upstream revision | a7c9930 |
| official RV32I/I tests built | 39 / 39 PASS |
| official tests runnable on P14 unmodified | 0 / 39 NOT RUN |
| official tests passed on P14 | 0 |
| official tests failed on P14 | 0 |
The important distinction: this is NOT RUN, not FAIL. The official tests build, but none fit the P14 execution model.
The smallest generated ELF was I-nop-00.S: 632 instruction words and
1384 bytes of data/signature sections. P14 has 32 instruction words,
8 zeroed data words, no data preload path, and no signature export.
The official framework also initializes and uses full RV32I registers
x16..x31; P14 is RV32E and intentionally treats those as absent.
So the gap is now concrete:
- More instruction memory, or a loader that can stream longer tests.
- A data-memory preload path.
- A signature export path.
- Full RV32I register file, or RV32E-specific generated tests.
- Sub-word memory ops if we want
LB/LBU/LH/LHU/SB/SH. - Trap/CSR/system behavior before anything privileged or exception related can be meaningful.
Artifact:
projects/14_rv32e_flash_boot/compliance_probe/rv32i_I_probe.csv.
Dry conclusion: P14 is good enough to make the failure mode interesting, not big enough to be invited to the official party.