CPU Design · All levels

TLB and Address Translation

Cache & Memory Hierarchy: Hierarchical TLBs and page-table walkers convert virtual addresses quickly; misses and shootdowns can stall both fetch and load pipelines if translation caching is undersized.

What this topic teaches

TLB and Address Translation turns CPU design theory into actionable review decisions. Hierarchical TLBs and page-table walkers convert virtual addresses quickly; misses and shootdowns can stall both fetch and load pipelines if translation caching is undersized. The target is evidence-backed closure, not opinion-driven tuning.

Senior-engineer framing question

When TLB miss rate, page-walk latency, and translation shootdown overhead shifts, can you prove first failing stage, dominant mechanism, accountable owner, and release-safe mitigation?

diagram
CPU PIPELINE VIEW - TLB and Address Translation

fetch -> decode -> rename -> dispatch -> execute -> retire
  |        |         |          |         |         |
icache   uop flow   map table  queueing  FU ports  ROB commit

steady-state goal:
keep every stage supplied without bubbles or flush storms

Focus: connect metric movement to the first stage loss
Metric tracked: TLB miss rate, page-walk latency, and translation shootdown overhead

Architecture visuals

Draw the mechanism before changing knobs. These visuals are optimized for design reviews and interview whiteboards.

Translation caches in memory stack

diagram
CPU CACHE + MEMORY HIERARCHY - TLB and Address Translation

                 [ L1I ]   [ L1D ]
               32-64KB, ~4 cycles
                      \     /
                       [  L2  ]
                 512KB-2MB, ~12 cycles
                           |
                         [ L3 ]
               shared LLC, 30-60 cycles
                           |
                    [ DDR/HBM memory ]
                    80-150ns effective

Optimization lens: overlay TLB behavior with cache levels and page-walk penalties

Page-walk feedback into pipeline

diagram
CPU PIPELINE VIEW - TLB and Address Translation

fetch -> decode -> rename -> dispatch -> execute -> retire
  |        |         |          |         |         |
icache   uop flow   map table  queueing  FU ports  ROB commit

steady-state goal:
keep every stage supplied without bubbles or flush storms

Focus: show how translation misses stall fetch and load-use latency
Metric tracked: TLB miss rate, page-walk latency, and translation shootdown overhead

Out-of-order control map

diagram
OOO CORE BLOCK DIAGRAM - TLB and Address Translation

decode -> rename -> dispatch -> reservation stations -> execute units
             |                        |                    |
       free-list / map table       wakeup-select         writeback
             \                        |                    /
              +-------- reorder buffer / retire ---------+

Focus: rename to retire dataflow

Memory hierarchy map

diagram
CPU CACHE + MEMORY HIERARCHY - TLB and Address Translation

                 [ L1I ]   [ L1D ]
               32-64KB, ~4 cycles
                      \     /
                       [  L2  ]
                 512KB-2MB, ~12 cycles
                           |
                         [ L3 ]
               shared LLC, 30-60 cycles
                           |
                    [ DDR/HBM memory ]
                    80-150ns effective

Optimization lens: latency vs capacity tradeoff

Speculation lens

diagram
BRANCH PREDICTOR VIEW - TLB and Address Translation

fetch PC -> BTB lookup -> direction predictor -> target select -> fetch redirect
               |               |                    |
          BTB miss cost     confidence         RAS / indirect path

branch resolves in execute:
correct prediction  -> pipeline keeps flowing
mispredict          -> flush + restart + refill

Focus: minimize wrong-path work

Ownership layers

diagram
CPU OWNERSHIP LAYERS - TLB and Address Translation

artifact area     owner
----------------  ----------------------------
architecture    MMU architect
RTL/microarch   OS kernel owner
software/tools  firmware performance owner

Rule: every regressed metric must map to an explicit owner and closure artifact.

Evidence required

  • Primary metric: TLB miss rate, page-walk latency, and translation shootdown overhead.

  • Primary artifact: TLB walk trace, page-size distribution report, and shootdown event log.

  • Owners to include: MMU architect, OS kernel owner, firmware performance owner.

  • One reproducible failing workload and one stable comparator run.

  • One run with fully locked environment metadata for causal comparison.

Compute-memory limit lens

diagram
CPU ROOFLINE - TLB and Address Translation

performance
   ^
   |                 compute roof
   |                /
   |               /
   |--------------/---------------- memory roof
   +----------------------------------------------> arithmetic intensity
      memory-bound                 compute-bound

Interpretation: separate compute and memory limits

Key takeaways

  • Classify stage loss before proposing fixes.

  • Use artifacts to separate mechanism from symptoms.

  • Close with owner accountability and rollback criteria.

Common pitfalls

  • Using average IPC alone while ignoring tail behavior.

  • Comparing traces across mismatched binaries or thermal states.

  • Calling closure without workload-level validation.

CPU deep dive

Memory hierarchy closure needs cache, TLB, and prefetch policy to be tuned together for real latency tails.

Concept diagram

diagram
MEMORY + TRANSLATION STACK

L1I/L1D -> L2 -> LLC -> DRAM
   |       |      |
 ITLB/DTLB hierarchy + page walkers

Metric graph

diagram
LATENCY TAIL CONTRIBUTORS

cache miss chains      █████
translation misses     ████
coherence interference ███

Reports and artifacts

  • L1/L2/LLC latency stack

  • TLB walk profile

  • prefetch usefulness report

  • memory tail percentile dashboard

Mini case study

Prefetch aggressiveness improved average misses but worsened p99 latency by polluting LLC and stressing page walkers.

Debug branches

  • Tag misses by source: capacity, conflict, translation, or coherence

  • Track TLB shootdowns and page-size behavior with workload phases

  • Evaluate prefetch policy on tail latency, not just average CPI

Senior review question

Ask: which CPI/latency evidence proves this topic is truly closed beyond synthetic benchmarks?

Key takeaways

  • Always connect microarchitectural counter changes to product workload outcomes.

  • Lock binary, compiler, firmware, and thermal metadata before comparing CPU traces.

Common pitfalls

  • Treating average IPC as sufficient proof while ignoring latency tails and outliers.

  • Applying predictor or prefetch tweaks without first-failing-stage attribution.

  • Declaring closure without reproducible perf, correctness, and power gates.