RP2350Sharp coverage heatmap

Which instructions, encodings, registers and datasheet sections are exercised by tests. Denominators come from the specifications (RP2350 datasheet, Armv8-M ARM, pico-sdk SVD), never from what the emulator implements.

Overview

Peripherals — tile area follows register count, colour follows the share of registers verified.

Instructions by family

verified: a test with an oracle ran it. verified by differential: only a lockstep comparison against QEMU ran it (an independent reference, not a spec-derived assertion). exercised only: only fuzzing or firmware ran it, nothing asserted its result. never run: no test executed it. Click a chip for its specification reference.

Encoding space

One pixel per encoding, so the gaps in the decoder's input space are visible. Dark = not an instruction in the catalogue and never run; teal = executed identically to QEMU in lockstep (the exhaustive sweeps record only the encodings on which both agreed; an unallocated encoding both machines reject with the same fault also counts; a Thumb-2 first halfword is teal once its sampled second halfwords agree and none carries an open or known-limitation disagreement); blue = run although no catalogue entry matches (reserved and undefined probes); grey = reserved, UNPREDICTABLE or implementation defined in the specification, listed by the PIO sweep and by the Arm reference-interpreter sweep (no oracle can exist). Green on the Thumb maps means the emulator agreed after every step with a reference interpreter (ThumbRef) that was written from memory of the Armv8-M ARM and then checked line by line, in three passes on 2026-10-26, against the text of DDI0553A.m (October 2019, a third-party copy, not the current release): the decode tables, the Encoding, Decode and Operation of all 309 instruction pages (integer, DSP, SIMD, load/store, system, hint, coprocessor and floating-point, including VLLDM / VLSTM and the lazy state preservation) and the shared pseudocode (shifts, saturation, IT, ExecuteFPCheck, RSPCheck, the floating-point rounding and NaN rules). A violated should-be-zero or should-be-one bit counts as agreement when the emulator produced any of the four outcomes C1.7 permits (UNDEFINED, NOP, as if the bit had its drawn value, UNKNOWN destination). A Thumb-2 first halfword is green when every sampled second halfword agreed, was UNDEFINED in both, or is unspecified; green outranks teal. Grey stays for what the sources leave without a behaviour: in the Thumb-16 map plain UNPREDICTABLE (CMP or ADD with PC, BX/BLX with Rm = SP/PC; the manual contradicts itself on SP), in the RVC map the reserved code points of the C, Zcb and Zcmp tables, in the PIO map the reserved fields. Every grey class has a row, with the sentence that makes it grey, in docs/VERIFICATION.md section 18, "Grey cells", and UnspecifiedClassTests fails when a class holds an encoding the sources define. A CONSTRAINED UNPREDICTABLE encoding with a closed list of outcomes (empty or STM-with-base register lists, CMP of two low registers, IT with firstcond 1111, CPS with I = F = 0) is green when the emulator did one of them; STM encoding T1 with its base register in the list is defined (that word is UNKNOWN) and green; C.SLLI / C.SRLI / C.SRAI with shamt[5] = 1 are designated for custom extensions, Hazard3 has none, and they are green as illegal instructions. BXNS and BLXNS are specified but the reference has no Secure state, so they are a gap, not grey; the Secure-state instructions SG, BXNS, BLXNS and TT are checked by directed tests only. Green does not mean silicon was compared, that the second halfwords were enumerated (they are sampled from the encoding patterns), or that the exception machinery was asserted (EXC_RETURN checks, tail-chaining, FPCCR banking and the Non-secure FP access, the stack-limit check at exception entry, the Secure transitions beyond the directed tests, the MPU, the SAU, CCR.UNALIGN_TRP); where the manual is silent or contradicts itself the encoding is grey, not green. The explicit list is docs/VERIFICATION.md section 18, "Still unverified". An instruction counts as verified once any one of its encodings ran under an oracle test, so these maps are stricter than the chips above: most of the space is only swept, not asserted.

PIO MOV matrix

Destination × source for each operation (none, invert ~, bit-reverse ::), datasheet 11.4.10.

Peripheral registers

One square per register in address order. A register is verified when both directions it supports were exercised by oracle tests (reset value, round trip, access type).

Datasheet sections cited by tests

Every section of the datasheet's functional chapters (2 to 13). Colour is the number of tests that cite the section in [Trait("Spec", …)] (red 0, amber 1–2, green 3 or more). This measures traceability to the datasheet, not behavioural completeness.