P129 asks whether the current frontend/backend split is a real
abstraction yet. It keeps P128’s queue-lifetime model and adds separate
frontend arrival and backend service counters for integer, memory, and
control work. The architectural core is unchanged.
check
result
Verilator build
PASS
BusyBox shell workload reaches P129-FILE-OK
PASS
Arrival/service counters emitted
PASS
Hardened layout
NOT RUN
arrival/service counter
integer
memory
control
arrivals
13,098,026
3,245,358
6,310,289
backend services
13,098,026
3,245,299
6,310,289
full drops
0
0
0
max occupancy
1
1
1
ready-mask counter
value
samples
50,443,768
single ready
50,443,768
dual ready
0
triple ready
0
integer ready
27,849,874
memory ready
9,973,316
control ready
12,620,578
two-issue opportunity cycles
0
three-issue opportunity cycles
0
trap flush clears
58
metric
P128
P129
post-load cycles
218,746,401
218,413,661
shell window cycles
64,776,985
64,498,976
retired instructions
86,351,273
86,239,296
CPI
2.5332
2.5326
S_FETCH cycles
7,627,087
7,622,465
S_MEM cycles
27,750,591
27,700,817
This is a useful negative result. Even after moving arrival accounting
earlier than P128’s accepted-record queues, the arrival and service
counts still track each other almost exactly. Each queue maxes at
occupancy 1. The current split is still instrumentation around a
monolithic in-order FSM, not a proper ready/valid frontend/backend
contract.
P130 should extract that contract explicitly with plain
LibreLane-friendly ready/valid modules and attach counters to handshake
events rather than inferred FSM windows.