Microarchitecture — OoO, DynamIQ, PMU

• BTB (Branch Target Buffer) — direct branches. Modern cores: 2-level, 2k-4k entries L0 + 16k+ entries L1.
• Indirect predictor — for BR Xn. Smaller (hundreds of entries) but often path-hashed for vtable dispatch.
• RSB (Return Stack Buffer) — predicts return targets. 16 entries typical. Overflows to BTB.
• Conditional predictor — evolved from 2-bit counters → tournament → TAGE / TAGE-SC-L. State-of-the-art as of Cortex-X4/X925.
• Perceptron predictor — seen in some custom cores (early AMD K10, rumoured Apple). Weighted sum of history bits.
• Flow: fetch block ⇒ predict targets + directions ⇒ redirect fetch same cycle. Latency of redirect = branch mispredict penalty cycles.

• 2011: Cortex-A15 + A7 pairing — first big.LITTLE. A15 was a power-hog OoO, A7 a tiny in-order.
• Coherency glue: CCI-400 (ACE-based Cache Coherent Interconnect) kept the two clusters' L2 caches coherent when threads migrated.
• Three operation modes:
  • Cluster Migration (CM) — all cores in one cluster at a time
  • CPU Migration (IKS) — pair each A15 with an A7, only one runs
  • Global Task Scheduling (GTS) — Linux sees all cores; scheduler migrates freely
• Problems: migration latency (>100 µs), OS scheduler bugs, two fixed clusters ⇒ rigid SKUs. iOS never adopted big.LITTLE — Apple went straight to a single-cluster heterogeneous design.

• Launched with Cortex-A75 / A55 in 2017. Replaces big.LITTLE's two-cluster model.
• One cluster containing up to 8 (DSU-110) or 14 (DSU-120) cores of mixed type.
• Integrates:
  • Snoop filter + SCU (coherence)
  • L3 cache — up to 16 MB shared across the cluster
  • Asynchronous bridges to the SoC fabric (CMN mesh, NIC, GIC)
  • Per-core DVFS domains — each core has its own clock + voltage
• Typical 2024 flagship cluster: 1 × Cortex-X925 + 3 × A725 + 4 × A520 on a DSU-120.
• Latency between any two cores' L1 is one DSU snoop — dramatically lower than CCI-400 inter-cluster latency.

• Modern phone SoCs have ~5-7 W sustained power budgets. Bursts to 12 W cause thermal throttling within ~30 s.
• Benchmarks (Geekbench, Antutu) run single-thread peaks → X-cores are for < 1-second bursts.
• Day-to-day browsing & app scrolling uses 1-3 mid cores — sustained efficiency zone.
• Background work (notifications, network, music) runs on little cores at 1-2× lower W/perf.
• The schedule mapping happens through Android EAS (Energy Aware Scheduling) which models each core's capacity and energy curve.
• Thermal headroom is what the next-generation wars are being fought over. Dimensity 9300 dropped little cores entirely (3 × X4 + 4 × A720) to maximise peak; criticised for sustained battery life.

• Armv8-A PMU: 1 cycle counter (PMCCNTR_EL0) + 6 programmable counters (PMEVCNTR0-5_EL0) per PE.
• Events selected via PMEVTYPER — hundreds of events (cache misses, BP mispredicts, stalls, retired instructions).
• Common events:
  • CPU_CYCLES, INST_RETIRED
  • L1D_CACHE / L1D_CACHE_REFILL
  • BR_MIS_PRED_RETIRED
  • STALL_FRONTEND / STALL_BACKEND
  • Topdown Armv8.8-A events (BAD_SPEC etc.) for Intel-style topdown analysis
• Linux perf and Android simpleperf both consume PMU directly.

// Program PMU counter 0 = L1 D-cache miss
msr   pmselr_el0, xzr            // select counter 0
msr   pmxevtyper_el0, #0x03      // L1D_CACHE_REFILL
msr   pmcntenset_el0, #1         // enable counter 0

// Run workload...

msr   pmcntenclr_el0, #1         // disable
mrs   x0, pmxevcntr_el0          // read count

// Linux equivalent
// $ perf stat -e l1d_cache_refill ./bench

v8.6 adds MPMM (Multi-PMU virtualization) so a guest can have its own PMU view.

• PMU counts events in aggregate. SPE samples individual executed operations — like Intel PEBS, AMD IBS.
• Every Nth retired µop writes a sample record to a dedicated memory buffer:
  • Instruction PC + virtual address of any memory reference
  • Latency of that operation
  • Outcome (hit / miss / TLB miss / fault / mispredict)
• Enables:
  • Accurate per-instruction attribution of cache misses, mispredicts, TLB misses
  • Cycle counting histograms per source line
  • Data-reference profiling for memory layout optimisation
• Linux perf record -e arm_spe// harvests the buffer.

• Modern big Cortex-A: 2 load + 2 store pipes (X1+ has 3 load).
• Store buffer: 40-60 entries. Coalesces consecutive stores to same line before committing to L1.
• Memory dependency prediction — speculates whether a load depends on an earlier store in the queue. Mispredict → replay the load.
• DSB stagger — when a real DSB drains the store queue, it blocks the pipeline for tens of cycles. One reason release/acquire is preferred.
• Atomic fast-path: LSE atomics (CAS, LDADD) bypass the store queue and go straight to the cache controller with a near-atomic request.

• Tuning switches — compiler picks instruction scheduling & feature subsets per core:
  • -mcpu=cortex-x4
  • -mcpu=neoverse-v2
  • -march=armv9-a+sve2+bf16
• Function-level hints:
  • __attribute__((target("sve"))) — dispatch-by-target
  • __builtin_prefetch(p, rw, locality) → PRFM
  • __builtin_arm_mte — MTE intrinsics
• Pragma-level: #pragma GCC ivdep, #pragma clang loop vectorize(enable).

// Compiler-targeted optimisation

// Force SVE code-gen path
__attribute__((target("+sve")))
float sve_dot(const float *a, const float *b, size_t n) {
  // compiler will emit VLA SVE loop
  ...
}

// Prefetch hint
for (size_t i = 0; i < n; i += 64) {
  __builtin_prefetch(&arr[i + 128], 0, 0); // PRFM pldl1strm
  process(&arr[i]);
}

// Runtime dispatch (outline atomics style)
ifunc impl = runtime_has_sve() ? sve_kernel : neon_kernel;

• Every Neoverse core is a re-characterised Cortex-A:
  • Neoverse N1 = Cortex-A76 (2018)
  • Neoverse V1 = Cortex-X1 + 2×256-bit SVE (2021)
  • Neoverse N2 = Cortex-A710 (v9-A)
  • Neoverse V2 = Cortex-X3 + 4×128-bit SVE (2022)
  • Neoverse V3 / N3 (2024) — shares front-end DNA with X4 / A720
• Server-side changes:
  • Dedicated CMN mesh (not DSU)
  • RAS, MPAM, SBSA compliance
  • More L2 + SLC, wider memory I/F (DDR5 / HBM)
• See the Neoverse Presentation Series for the server story.

• Across the 6 decks:
  • 01 History — why the family looks the way it does
  • 02 Architecture — ELs, A64, system regs
  • 03 Memory — VMSA, caches, ordering, atomics
  • 04 Vectors — NEON → SVE → SVE2 → SME
  • 05 Security — TrustZone, EL2, PAC/BTI/MTE, CCA
  • 06 Microarchitecture — OoO, DynamIQ, PMU
• Together they cover what a phone/SoC/kernel Arm engineer is expected to know — and what a Neoverse engineer needs before deck 01 of that series.

• "Why did A76 shorten the pipeline vs A72?" → higher IPC + lower mispredict cost + 7 nm process allowed physical designs with fewer stages at same clock.
• "Explain DynamIQ vs big.LITTLE" → one cluster, many core types, shared L3, per-core DVFS; vs two fixed clusters, separate L2s, CCI-400 inter-cluster coherence.
• "Why is RSB important?" → returns are indirect but deterministic — a small RSB predicts them perfectly. Attackers have exploited RSB underflows for Spectre-RSB variants.

• "What's the difference between PMU and SPE?" → PMU counts events in aggregate; SPE samples individual operations with per-op latency & attribution.
• "Why 1+3+4?" → thermal + benchmark + efficiency blend. 1 X for burst benchmarks, 3 mid for sustained, 4 little for background — fits a 5-7 W budget.
• "Why does Arm keep making L3 bigger?" → DRAM bandwidth per core didn't grow at Moore rate. Larger L3 hides more misses. X925 + DSU-120 pushes toward laptop-sized LLCs.
• "DSU vs CMN?" → DSU is a cluster-level shared L3 + snoop filter; CMN is a system-level mesh that connects multiple DSUs + I/O + memory controllers.

• Bigger front-ends — 10-wide decode likely permanent; Apple-class 12-16-wide within reach.
• SVE2 as default vectors — NEON in compat mode only.
• SME on flagships — matrix units as standard for on-device LLM.
• Memory tagging universal — MTE async in every Armv9-A shipping kernel.
• Laptop-class Cortex-A — Windows-on-Arm + Android XR + Chromebook share the same X-core die budgets.
• CCA on phones — protected media + on-device AI inference in Realm world.