Modeling the Heterogeneous SoC: Models of Computation Meets Pre-Silicon Simulation

From one memory system to a whole SoC

The two preceding studies modeled one engine and the memory beneath it. The cache-size investigation probed latency — when the working set fits, what it costs in energy. The bandwidth study probed the orthogonal axis, memory-level parallelism, and found that the fastest DRAM is only fast when enough requests are in flight to use it. And the portable GPU methodology case study argued that on a real accelerator the binding constraint is memory movement, not arithmetic, and that the right place to reason about that is a modeled memory system — before the hardware exists.

This post takes the next step. The unit of design is no longer a CPU and its cache hierarchy. It is a heterogeneous SoC — a CPU, a GPU, and an NPU sharing one memory fabric — and the hard problem has moved from inside any one engine to the boundaries between them.

The thesis: heterogeneous-SoC performance is a models-of-computation problem

In 2003 Axel Jantsch formalized a taxonomy of Models of Computation (MoC) — a precise language for how concurrency and time compose in a system [1]. What read then as embedded-systems theory is now an empirical description of every low-wattage APU, rediscovered the hard way and without the vocabulary.

The mapping is almost one-to-one:

The first three rows are solved-enough in isolation: each engine has a mature execution model. The pain is in the fourth.

The interface is the unsolved part

Jantsch devotes a chapter to MoC interfaces — what happens where two models of computation with different temporal semantics meet. That is precisely the CPU↔NPU↔GPU handoff: an untimed dataflow NPU feeding a synchronous iGPU feeding a timed real-time pipeline, all over one memory fabric, all contending for the same bandwidth the bandwidth study showed is only usable under parallelism.

The combinatorics are brutal. A recent characterization of even a simple CPU+GPU+NPU video-conferencing workload put its scheduling space at roughly O(2¹²⁵) [2]. That is not a tuning problem you brute-force; it is a search over temporal-semantic compositions — exactly the object Jantsch's interface formalism was built to describe. The formal tools to reason about it cleanly have existed for two decades; industry has largely been solving it by trial and error on shipping silicon.

Different clocks, coupled components: the flux-iteration analogy

There is a precise analog for why the interface is hard, and it comes from fusion modeling. A heterogeneous SoC is a multi-rate system: the NPU advances on a tensor-dispatch cadence, the iGPU on a wavefront/barrier cadence, a real-time pipeline on a fixed deadline — components living on different temporal scales, exactly like the fast and slow processes of a coupled plasma (turbulence, transport, equilibrium evolve orders of magnitude apart).

Fusion simulation does not solve such a system monolithically. It models each piece separately and couples them at their interfaces by exchanging fluxes, iterating back and forth until the shared boundary state is self-consistent — a Picard / fixed-point sweep between component solvers on different clocks. The CPU↔NPU↔GPU handoff has the same shape: each engine is a component model, the data crossing the boundary is the flux, and getting the temporal semantics right means iterating the handoff to consistency rather than assuming one global clock.

And the moment you advance a coupled multi-rate system in time, you inherit the Runge–Kutta-like integration phenomena that coupling is notorious for: operator-splitting error, order reduction, and stiffness/stability limits when a fast component is sub-cycled inside a slow one. How you interleave the stages — which component sees which other's state, and when — is not a detail; it sets the accuracy and stability of the whole coupled advance. This is why an SoC schedule is not a static assignment but a temporal-integration scheme, and a large part of why its design space explodes the way the interface count suggests.

This multi-rate-coupling framing — flux exchange with iterative consistency and Runge–Kutta-like stability behavior — is long-standing in computational fusion modeling, most directly in core–edge transport coupling: separate core, edge, and wall models matched by flux at their interfaces and iterated to consistency, the structure of the DOE SciDAC FACETS framework [5].

This is not a borrowed analogy. I worked on it directly as part of the FACETS team, coupling core, edge, and wall solvers — each living on its own timescale — by matching fluxes at their interfaces and iterating to a self-consistent state. The CPU↔NPU↔GPU interface is that same problem in new clothing: different models of computation, different clocks, made to agree at a boundary. It is also the daily reality of the coupled transport and equilibrium solves in the plasma-PINN campaign, where the pieces are advanced together to a self-consistent state. The same operator-coupling discipline that keeps a tokamak transport solve stable is what a heterogeneous-SoC scheduler needs at its component interfaces.

Nondeterminism and on-device agents

The later Jantsch chapters — process networks, nondeterminism, probability — read as a specification for the workload now arriving on the edge: on-device agentic applications, which demand concurrency, state dependency, speculative decoding, and real-time interactivity all at once [2, 3]. Preemptive multi-engine (multi-XPU) scheduling is an open systems problem with fresh research attention [4]; framed correctly, it is applied MoC-interface theory.

Why pre-silicon simulation is the right instrument

You cannot tune what does not exist yet, and you cannot reason about a temporal boundary from a datasheet. Cycle-level simulation can: gem5 advances a modeled clock through the pipelines, the memory controllers, and the fabric, and McPAT turns the resulting activity into power and area. These are the same instruments used in the two prior studies to find the energy-optimal cache and the bandwidth/MLP crossover — now pointed at the interfaces rather than at one engine.

Two results from the earlier studies carry directly into the SoC setting:

• The latency-vs-MLP distinction from the bandwidth study is exactly what governs a CPU→NPU handoff over a shared fabric: a serialized handoff pays full latency; a pipelined one needs enough independent work in flight to hide it — the same memory-level-parallelism argument, now at the interface.
• The residency lesson from the PENNANT study — that the killer is data crossing a slow boundary, and the lever is keeping it resident rather than overlapping the crossing — is the discrete-GPU preview of the on-package APU fabric, where the boundary is cheaper but never free.

A modeled fabric lets you place these effects on a roofline and predict where a proposed CPU/NPU/GPU partition will bind, before committing it to silicon.

Theory, validated against measurement

The formalism has existed since 2003; what has been missing in practice is the measurement infrastructure to validate a model against real hardware — the roofline analysis, correctness gating, and artifact-resistant measurement that the rest of this work is built on. The combination is the point: a formal MoC model of an SoC, simulated pre-silicon, and then checked against measured silicon, is how you reason about a heterogeneous design cleanly — instead of searching an O(2¹²⁵) space by trial and error after tape-out.

References

1. A. Jantsch. Modeling Embedded Systems and SoC's: Concurrency and Time in Models of Computation. Morgan Kaufmann, 2003.
2. R. Karami, R. Patwari, H. Kwon, A. Sirasao. "Exploring the Dynamic Scheduling Space of Real-Time Generative AI Applications on Emerging Heterogeneous Systems." arXiv:2507.14715, 2025. (Source of the ~O(2¹²⁵) scheduling-space figure for a video-conferencing workload on a Ryzen AI CPU+iGPU+NPU SoC.)
3. X. Wei, J. Zhang, et al. "Agent.xpu: Efficient Scheduling of Agentic LLM Workloads on Heterogeneous SoC." arXiv:2506.24045, 2025.
4. W. Shen, M. Han, J. Liu, R. Chen, H. Chen. "XSched: Preemptive Scheduling for Diverse XPUs." USENIX OSDI, 2025.
5. DOE SciDAC FACETS (Framework Application for Core-Edge Transport Simulations) — flux-coupled core–edge transport with implicit, iterative interface consistency: J. R. Cary et al., "Introducing FACETS, the Framework Application for Core-Edge Transport Simulations," J. Phys.: Conf. Ser. 78, 012086 (2007); and J. R. Cary, A. Hakim, … S. Vadlamani, … T. Epperly, et al., "FACETS — a Framework for Parallel Coupling of Fusion Components," arXiv:1004.1611 (2010). See also Cary, Epperly, et al., "Concurrent, parallel, multiphysics coupling in the FACETS project," J. Phys.: Conf. Ser. (SciDAC, 2009).