The first P17 failure looked like an architecture bug. It was not.
Tracing I-lui-00.S around the first failing check showed this:
| PC | instruction | observed |
|---|---|---|
0x21c | lui x1,0x9094f | core wrote 0x9094f000 |
0x220 | lw x4,0(x2) | signature memory returned 0x00000000 |
0x224 | beq x4,x1,... | fail branch taken |
So the core had the right LUI value. The harness was wrong: our
RVTEST_SELFCHECK signature file was all zeros after the canary.
P18 changes the P17 batch runner to emit per-test signatures. I-lui-00.S
and I-addi-00.S now have generated signatures. The fallback for the rest
remains zero-filled, which is intentionally not a full-batch compliance claim.
Command:
make -C projects/18_rv32i_lui_signature_debug/test
Result: PASS
| test | result |
|---|---|
I-nop-00.S | PASS |
I-fence-00.S | PASS |
I-lui-00.S | PASS |
I-addi-00.S | PASS |
That gives P18 four official RV32I tests through the P17 UART/external-memory path, including two real instruction classes.