P135 keeps P134’s aux-load policy and adds mutually exclusive block
buckets. The question is which background-fill guard actually blocks
otherwise-safe aux-load opportunities.
check
result
Verilator build
PASS
BusyBox shell workload reaches P135-FILE-OK
PASS
Aux-load queue full drops
PASS
Aux response errors/cancels
PASS
Hardened layout
NOT RUN
metric
P134
P135
post-load cycles
218,247,567
219,445,401
shell window cycles
64,221,642
65,411,939
retired instructions
86,139,760
86,534,503
CPI
2.5336
2.5359
S_FETCH cycles
7,617,695
7,634,641
S_MEM cycles
27,799,343
27,975,703
P135 is not a speedup rung. The value is the attribution.
aux-load counter
P134
P135
candidates
5,372,186
5,418,028
issues
139,881
140,540
queue enqueues
139,881
140,540
queue dequeues
139,881
140,540
queue full drops
0
0
aux load fills
139,881
140,540
P135 mutually exclusive bucket
count
frontend prefetch not safe/useful
1,596,970
frontend-ready candidates
3,821,058
background quiet candidates / actual issues
140,540
blocked by D-cache background only
196,378
blocked by I-cache background only
1,620,547
blocked by both backgrounds
1,863,593
The next target is clear: D-cache-only blocks are small. I-cache
background activity is the larger single guard. P136 should test whether
a useful next-PC prefetch plus aux-load issue can preempt I-cache
background fill while still keeping D-cache background fill quiet.