Single-cycle fetch on TLB hit (the easy half of a 2-stage pipeline)

P62’s profile pinned S_FETCH at 32% of all post-load cycles — two cycles per retired instruction. The first cycle evaluated the TLB lookup and set fetch_xlated_q; the second cycle issued the mem-fetch and latched ir. P63 collapses that into a single cycle on the TLB-hit path, which is 96.5% of fetches.

Headline: ~17% fewer cycles to userspace exec versus P62. The full F/X parallel pipeline is queued up as P64 — P63 ships the easy half so the chart progression has an honest first column.

The change

The mem-issue combinational now consults the TLB result directly instead of waiting on fetch_xlated_q:

// Before (P62): two cycles in S_FETCH on TLB hit
//   cycle 1 — evaluate TLB, set fetch_pa_q + fetch_xlated_q
//   cycle 2 — issue mem (mem_addr = fetch_pa_q), latch ir
mem_valid = (state == S_FETCH && (!translation_active || fetch_xlated_q));
mem_addr  = fetch_xlated_q ? fetch_pa_q : pc;

// After (P63): one cycle in S_FETCH on TLB hit
//   cycle 1 — TLB hit drives mem_addr, latch ir on mem_ready
mem_valid = (state == S_FETCH &&
             (!translation_active || fetch_xlated_q ||
              (tlb_fetch_hit && tlb_fetch_x &&
               !priv_u_violates_fetch(tlb_fetch_u))));
mem_addr  = fetch_xlated_q   ? fetch_pa_q
          : translation_active ? tlb_fetch_pa
                               : pc;

The S_FETCH next-state logic was extended in parallel: on TLB hit + perm OK + mem_ready, latch ir and advance to S_DECODE in the same cycle. About 30 lines of diff.

The walker / post-walker / M-mode paths are unchanged — this is a pure addition for the common case.

Boot, annotated

The full sim run from chip reset through userspace exit to Kernel panic — Attempted to kill init. Every captured UART byte plotted onto the cycle axis where it landed. The “silent phase” you read about everywhere — that 100M-cycle gap between clocksource: Switched and Run /init — is right there, with the BLAKE2s entropy seeding sitting where it actually sits.

The 25.8% slice in phase 5 is what motivated P62’s Zbb rotates; the 32% slice in S_FETCH (spread evenly across phases 3–6) is what P63 attacks. The full F/X parallel pipeline coming in P64 will go after the same 32% from the opposite direction — by overlapping fetches with execute cycles instead of compressing each fetch.

Measured

The full sim ran end-to-end. The fast path saved exactly one cycle per TLB-hit fetch, applied across every retired instruction:

S_FETCH was nearly cut in half (the half it kept is the walker / post-walker / non-translation paths, which P63 didn’t touch). CPI dropped 0.97 — almost exactly one cycle per instruction, since fetches happen once per retire.

Boot milestones, every one moving by ~15.6%:

P62 → P63 progression

The benchmark harness’s whole point: every chip rev gets a new column of charts so the work is visible.

The state-comparison chart shows it cleanly. P63’s S_FETCH stripe is half the height of P62’s; everything else stays the same width because nothing else changed.

Where the chip is spending its cycles now

Instrumentation note: the testbench’s per-cycle TLB fetch-hit counter looked for fetch_xlated_q rising — a P61 hold-over that P63’s fast path bypasses (we go straight from S_FETCH to S_DECODE without setting that bit). The walker stats and total cycles are correct; the per-event TLB-hit counter reads 0 in this run. Will fix when P64 lands.

What’s next

• P64 — full 2-stage pipeline with a separate F-FSM running concurrently with the X side. Walker arbitration, fault staging, branch flush propagation. The expected win is another ~25% on top of P63 — fetch fully hides under execute for compute-bound code.
• P65 — 3-stage (decode separated).
• P66 — classic 5-stage MIPS with forwarding.
• P67 — synthesis baseline; finally measure fmax / area on sky130 so the speed planning has hardware truth in it, not just CPI math.

Harden

NOT RUN. Driving mem_valid from a TLB lookup adds the TLB priority encoder into the address-generation path — that’s the most likely place for an fmax cost. Will measure post-P66.

What just happened?

We noticed that the chip’s per-fetch overhead was an artifact of how fetch_xlated_q was wired sequentially, not a fundamental constraint. The TLB lookup is already combinational (P61). Letting the bus see that result directly saves a cycle for free, on every fetch, for the rest of the boot.