tx_fifo.r_en popped from txld_cnt >= 2, hard-coded for the old invented
2-byte header where the data phase began at slot 2. The real protocol's
register space uses a 4-byte header, so data starts at slot 4 -- two bytes
were being consumed before the GC clocked any data, and every register read
came back wrong. On hardware: HIPR and NWAYS both read 0x00, and the device
ID returned 01 80 c0 c0 (stale bytes, including our own header command bytes
0x80/0xC0 echoing back out of the FIFO).
The threshold is now derived from byte 0 bit 7, which is exactly what selects
the header form: register space -> 4 slots, command space -> 2 slots.
Also removes the pad-slot filler byte the register file was pushing. That was
compensating for this bug rather than fixing it -- it made the simulation pass
while hardware still failed, which is how it slipped through. With the pop
threshold correct the filler is wrong, and both the unit and integration
testbenches agree without it.
All suites pass: bba_register_file, bba_top, exi_capture, exi_j4,
spi_mode3_slave, tx_frame_drain, spram_arbiter, rx_frame_assembler,
w5100_parallel_master.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Roflin
399fbf02a4