P132 gives the dispatch queue module a shadow payload record. On
arrival fire, it captures decoded metadata: PC, opcode, rd, rs1, rs2,
and source-use bits. Architectural execution is still unchanged.
check
result
Verilator build
PASS
BusyBox shell workload reaches P132-FILE-OK
PASS
Payload counters emitted
PASS
Payload invariant errors
PASS
Hardened layout
NOT RUN
payload counter
value
accepts
22,654,694
services
22,654,627
flush clears
66
append without storage
0
invariant errors
0
module counter
value
samples
64,742,043
arrival-fire cycles
22,654,694
service-fire cycles
22,654,627
backpressure cycles
0
dual-ready cycles
0
triple-ready cycles
0
per-class counter
integer
memory
control
arrival fires
13,100,441
3,244,787
6,309,466
service fires
13,100,441
3,244,720
6,309,466
max occupancy
1
1
1
count at end
0
1
0
metric
P131
P132
post-load cycles
218,215,879
218,410,456
shell window cycles
64,299,031
64,505,052
retired instructions
86,172,041
86,240,322
CPI
2.5323
2.5326
S_FETCH cycles
7,618,031
7,622,395
S_MEM cycles
27,681,021
27,699,391
This is not a speedup rung. The important result is that payload
accepts match arrival fires, payload services match service fires,
payload flush clears account for the service/accept delta, and invariant
errors stay at zero.
The next step is payload-class auditing: compare the module-owned record
against the older issue-slot and memory/control holding classifiers
before using the payload to drive the backend.