P133 keeps architectural execution unchanged and asks one specific
question: when the dispatch queue module owns a payload record, does its
class agree with the older integer, memory, and control classifiers?
check
result
Verilator build
PASS
BusyBox shell workload reaches P133-FILE-OK
PASS
Payload counters emitted
PASS
Payload invariant errors
PASS
Payload class mismatches
PASS
Hardened layout
NOT RUN
class audit counter
value
total payload class audits
22,662,361
payload class mismatches
0
integer payload audits
13,103,082
memory payload audits
3,247,041
control payload audits
6,312,238
payload counter
value
accepts
22,662,361
services
22,662,289
flush clears
71
append without storage
0
invariant errors
0
module counter
value
samples
64,770,651
arrival-fire cycles
22,662,361
service-fire cycles
22,662,289
backpressure cycles
0
dual-ready cycles
0
triple-ready cycles
0
per-class counter
integer
memory
control
arrival fires
13,103,082
3,247,041
6,312,238
service fires
13,103,082
3,246,969
6,312,238
max occupancy
1
1
1
count at end
0
1
0
metric
P132
P133
post-load cycles
218,410,456
218,556,365
shell window cycles
64,505,052
64,581,917
retired instructions
86,240,322
86,293,679
CPI
2.5326
2.5327
S_FETCH cycles
7,622,395
7,626,643
S_MEM cycles
27,699,391
27,727,937
This is still a refactor rung, not a speedup rung. The useful result is
the zero mismatch count after a full Linux and BusyBox shell run.
The larger backend story is now clear: P123-P129 showed that the
current backend does not naturally create independent ready work. P130
through P133 made the dispatch boundary real enough to trust: named
valid/ready/fire, module-owned queue state, module-owned payload, and
class-audited payload ownership. The breakthrough has not happened yet;
the point is that the next active experiment now has a clean module
boundary instead of another loose counter cluster in top.sv.