ARM Cortex-X925 Microarchitecture: Branch Prediction and Cache Hierarchy

Cortex-X925 is ARM's third-generation X-series core under the rebranded “Blackhawk” program, and it is the most aggressive single-thread uplift ARM has shipped since the X1. With a 10-wide decode front-end, a redesigned hybrid branch predictor, and a doubled private L2, the core targets a 36% IPC gain over Cortex-X4 at iso-frequency while holding mobile power under 4W. For flagship SoCs like Dimensity 9400 and next-gen Samsung Exynos designs, that efficiency determines whether performance is sustainable or just a Geekbench spike.

This analysis dissects the two subsystems that define X925's real-world throughput: the decoupled branch prediction pipeline and the three-level cache hierarchy built around DSU-120. We will trace how instructions flow from fetch to retire, why mispredicts hurt less, and how the private L2 trade-off reshapes cluster floorplanning and mobile edge computing performance under thermal constraints.

1. Pipeline at a Glance: From 6-Wide to 10-Wide

X925 raises the front-end width without naively widening everything. Fetch itself remains 8-wide from the 64KB L1 I-cache, but the decode stage expands to 10 instructions per cycle, up from 6 in X4 and 8 in X3. ARM achieved this by splitting the legacy 6-wide decoder into two 5-wide clusters with independent pre-decode and micro-op cracking logic. Simple ALU ops still map 1:1, while complex loads with shift or SVE2 predicates crack into two micro-ops.

Behind decode, rename is 8-wide and dispatch is 10-wide into a rebalanced out-of-order window: ~410-entry reorder buffer (ROB), 240-entry rename pool, and distributed schedulers holding ~110 entries. The execution back-end fields four integer ALUs (two with branch resolution), three address-generation/load-store units, and two 128-bit SIMD/FP pipes that can fuse for 256-bit SVE2 operations. The key insight is that width only helps if the front-end keeps it fed — which is where branch prediction becomes the bottleneck.

2. Branch Prediction: TAGE-SC, ITTAGE, and Faster Redirect

On a 10-wide machine with an 11-stage mispredict penalty, every percent of MPKI (mispredicts per kilo-instructions) costs measurable IPC. ARM quotes a 12–13% reduction in MPKI versus X4 on SPECint 2017 and a larger 18% win on Android framework traces where indirect branches dominate. The improvement comes from three changes.

Hybrid TAGE with Statistical Corrector

The main direction predictor is now a tagged geometric history predictor (TAGE-SC) with eight tables indexed by geometrically increasing global history lengths (from 8 to 240 branches). Capacity grows to roughly 8K entries for the longest-history table, double X4's 4K, plus a loop predictor for tight counted loops and a 2K-entry statistical corrector (SC) that learns from TAGE's systematic bias — typically when history aliasing mispredicts correlated branches. The predictor runs ahead of fetch, delivering one taken branch per cycle and up to two with a folded branch target buffer (BTB).

Crucially, ARM added a second-level “FTQ” — a fetch target queue that decouples prediction from I-cache access. Even on an I-cache miss, the predictor continues running and queuing up to 24 fetch blocks. When the line returns, fetch can burst without starving decode. This hides L1 I misses that previously stalled the predictor in X1–X3 lineage.

Indirect Targets and Returns

Mobile code is indirect-heavy: virtual calls in Android Runtime, pointer authentication branches, and high-level UI dispatch. X925 introduces a dedicated ITTAGE (Indirect TAGE) structure with a 1K-entry target cache indexed by history, separate from the conditional TAGE. Combined with a 32-entry, two-way associative L1 BTB backing a 8K-entry L2 BTB, it cuts indirect mispredicts by 28% over X4 in ART benchmarks.

The return address stack (RAS) also deepens to 48 entries with speculative repair — earlier X cores flushed RAS on mispredict. X925 checkpoints RAS on each call and restores on redirect, avoiding the cascade of return mispredicts after a single wrong-path call.

Redirect Latency

Even a perfect predictor still mispredicts. X925 shortens the flush path from 13 cycles (X4) to 11 cycles by resolving branches earlier in the ALU pipes and broadcasting redirect to fetch in the same cycle. The decoupled queue means only the youngest ~16–20 instructions are flushed versus 30+ on X3, preserving prefetcher training and L1 locality after a mispredict.

3. Cache Hierarchy: Private L2 Grows Up

ARM's cache philosophy flipped at X4: the private L2 became mandatory and inclusive, and X925 doubles down. Each X925 core owns its own L2, distinct from the DynamIQ Shared Unit (DSU-120) L3. The configuration spectrum documented in r0p0 is:

• L1 I-cache: 64KB, 4-way, 64B lines, parity-protected, 3-cycle hit
• L1 D-cache: 64KB, 4-way, 64B lines, ECC, 4-cycle load-to-use, 4× 128-bit read ports via banking
• Private L2: 1MB, 1.5MB, or 2MB, 8-way, inclusive of L1, 26-cycle load-to-use at 2MB (24c at 1MB), 32B/cycle per direction
• DSU-120 L3: 2MB–12MB shared, 16-way, 35–48 cycles depending on slice, up to 8 cores

Inclusive L2 simplifies coherence — the L2 holds a superset of L1 tags, so snoops need only check L2. The trade-off is capacity efficiency, but ARM argues mobile working sets fit neatly: 64KB+1MB captures >92% of Android app footprint without spilling to shared L3, which reduces interconnect traffic and benefits biometric authentication pipelines where L3 contention can jitter latency.

Prefetching and Streaming

Each L1 and the private L2 carries its own stride prefetcher. The L1 D prefetcher tracks up to 32 streams with 4KB distance, the L2 prefetcher tracks 48 streams and can issue prefetches into L3 without polluting L2 unless confidence exceeds 75%. A separate instruction prefetcher monitors L1 I miss patterns and pushes next-line prefetches into L2. For contiguous media workloads, ARM shows bandwidth rising from 28 GB/s (X4 cluster) to 38 GB/s under the same LPDDR5X-8533 PHY — largely because the private L2 filters 31% of L3 accesses.

DSU-120 Shared Fabric

The cluster-level DSU-120 remains the coherence point, supporting up to 14 MB combined L3 (when configured with 12 MB + core L2s). New in this generation is a dynamic exclusive/shared policy: L3 can be configured as exclusive to private L2s for large gaming workloads (avoiding duplication) or inclusive for background-task heavy use. The interconnect is AMBA 5 CHI with 32B data channels, supporting CHI cache stashing for accelerators — relevant for quantum-resistant crypto accelerators that benefit from stashing public keys directly into X925's L2.

4. Out-of-Order Memory and Store Behavior

X925's load-store unit couples the larger window with a more aggressive memory disambiguation. The memory order buffer (MOB) holds 72 loads and 56 stores in flight. A 6K-entry memory dependence predictor learns store-load aliases using a hash of PC and address, allowing loads to bypass unresolved stores with ~98.5% accuracy.

Two load pipelines can each deliver 32 bytes per cycle from L1, and store bandwidth is 32B/cycle via the 56-entry store queue that supports coalescing and 128-bit atomic vector stores for SVE2. For encrypted I/O paths, this matters: AES-XTS scheduling benefits from dual-load issue, while the larger store queue prevents ROB stalls during memcpy-heavy file encryption.

Memory tagging (MTE) and pointer authentication remain on the critical path. ARM reduced MTE tag-check latency by merging tag lookup with L1 access, so heap-hardened builds pay only ~1–2% overhead versus ~3% on X3. Realm Management Extension (RME) adds a granule protection check at L2, off the L1 critical path, preserving that 4-cycle load-to-use.

# Read CTR_EL0 to confirm cache line size and architecture
MRS  X0, CTR_EL0          // CTR: DminLine=64B, IminLine=64B, IDC/DIC present
MRS  X1, CLIDR_EL1        // Caches: L1 I/D + L2 + L3 via DSU-120
MRS  X2, CCSIDR_EL1       // Query L2 size: associativity=8, sets=2048 for 1MB

# Linux DT / ACPI PPTT fragment for a 1× X925 + 3× A725 + 4× A520 cluster
cpu@0: { compatible = "arm,cortex-x925"; reg = <0>;
         i-cache-size = <0x10000>;    // 64KB
         d-cache-size = <0x10000>;
         next-level-cache = <&L2_0>; }
L2_0: { cache-size = <0x200000>; // 2MB private, inclusive
        cache-level = <2>; cache-unified; }

# Prefetcher control (implementation-defined, EL3/EL1 trap)
MSR  S3_6_C15_C1_0, X3    // CPUECTLR_EL1: bits 12-14 L2 prefetch distance=8, stride=on

5. Physical Trade-offs and What It Means for SoCs

Width and predictor storage cost area. ARM lists X925 at ~1.42 mm² per core with 1 MB L2 on TSMC N3E (versus ~1.18 mm² for X4). Most of that delta is L2 data array and TAGE tables — both SRAM-heavy. Dynamic power is offset by clock gating: the decoupled fetch queue allows the predictor to sleep during correct-path bursts, and the second-level BTB is accessed only on L1 BTB miss, saving ~90 mW at 3.3 GHz on a Dhrystone loop.

For system designers, the recommendation is shifting: pair X925 with 2 MB private L2 for sustained gaming flagships, but stay at 1 MB for ultra-thin foldables where die area and leakage dominate. In either case, keep L3 at 4–8 MB for heterogeneous compute — the DSU slice is power-gated per cluster state, so unused L3 ways do not burn leakage during light use, which helps MEC workloads that burst to the X925 and park быстро.

On methodology, expect SPEC CPU 2017 int to be the best showcase for X925 (estimated +36% IPC), while web browsing traces see +15–20% due to front-end bound phases. Thermal throttling compresses the gap after 8–10 seconds; sustained power is the real differentiator, not peak Geekbench.

Bottom line: Cortex-X925 is not just a wider X4. By decoupling prediction, scaling TAGE-SC and ITTAGE, and making a large inclusive private L2 mandatory, ARM attacks the two historical mobile bottlenecks — branch mispredicts and L3 contention — at once. The result is a core that scales better with 3nm frequencies and LPDDR5X bandwidth, provided vendors invest the SRAM budget and tune prefetchers for Android's indirect-heavy reality.