KDI v0.1.1 — correction: rhd_matrix row order was off by one
If you built a decoder against v0.1.0, fix this first.
v0.1.0 published "rows 0..31 are amplifier channels in ascending order, rows 32..34 are the chip's three aux results". That is wrong in the most dangerous way available: a host implementing it reads channel n at row n and gets channel n−1, with row 0 pure garbage — plausible-looking neural data at the wrong index, with a valid CRC and correct lengths.
The RHD SPI returns a command's result during the next command, so row k carries the capture from command k−1:
| row | content |
|---|---|
| 0 | the previous timestep's aux2 (aux_adc) — it lags |
| 1..32 | amplifier channels 0..31, ascending |
| 33, 34 | this timestep's aux0 (temp) and aux1 (supply) |
This is the hardware, not a choice. An earlier revision shipped the un-rotated version once and a real RHD2132's ROM/ID answers missed their expected slots at every MISO delay; static-MISO simulations cannot see it.
No wire bytes change — only the published meaning of the rows. format stays 2, and the golden vector is unaffected (it carries a digital section, not an rhd_matrix one), so a decoder's framing, CRC and negative-case handling are all still correct as shipped.
Still not emitted by gateware: no bitstream produces format 2 and clean_frame stays clear.
Conformance 12/12. Source: keyvast-fpga@869bb93.