Cross-Domain Processing Unit (XPU)

• XPU is an umbrella term defining systems that bridge traditional processor boundaries by integrating computation across signal, device, and runtime domains.
• Analog-mixed-signal implementations like the C3PU achieve significant gains, reporting up to 3.4× lower energy and 3.6× smaller area compared to digital MAC units.
• As a heterogeneous abstraction, XPU enables optimized scheduling and resource coordination across CPUs, GPUs, DPUs, and other accelerators in diverse computing environments.

Searching arXiv for the cited XPU-related papers to ground the article in current literature. “Cross-Domain Processing Unit” (XPU) is not a single standardized term across the recent literature; rather, it appears in several adjacent senses that share a common premise: computation is organized across boundaries that conventional CPU-centric models treat separately. In analog-mixed-signal inference hardware, the term is used for a unit whose computation spans the voltage, time, current, and voltage domains within an in-memory multiply-and-accumulate engine (Kilani et al., 2021). In systems and runtime research, “XPU” more often denotes a heterogeneous processing environment comprising CPUs and other processing units such as GPUs, DLAs, NPUs, VICs, PVAs, ASIC-style engines, or DPUs, with software and scheduling abstractions designed to coordinate them explicitly (Han et al., 13 Aug 2025); (Yang et al., 31 Mar 2025). A related line of accelerator analysis work uses the term to refer to custom machine-learning accelerators whose execution must be understood at the machine-code and microarchitectural levels (Zarkadas et al., 18 Mar 2025). Taken together, these usages indicate that XPU is best understood as an umbrella designation for computation that crosses device, execution, or signal domains rather than a narrowly fixed processor class.

1. Terminological scope and principal usages

The recent arXiv literature uses “XPU” in at least three technically distinct ways. In distributed stencil computing, the term is explicitly defined to mean either GPU or CPU, with a programming model intended to preserve portability across those backends (Omlin et al., 2022). In autonomous runtime systems, “XPU” is a deliberately broad umbrella term for heterogeneous processing units, including CPU, GPU, DLA or NPU-like accelerators, and platform-specific engines such as VIC and PVA (Han et al., 13 Aug 2025). In cloud-native offloading systems, the term is used at the system level for a cross-processing-unit computer in which work is distributed across a CPU and one or more other processing units such as a DPU (Yang et al., 31 Mar 2025).

This terminological diversity matters because it shows that XPU is not synonymous with “accelerator” in the narrow sense. In some works, it identifies a portability layer over CPU and GPU execution (Omlin et al., 2022). In others, it denotes a schedulable heterogeneous resource pool whose members differ in both functionality and performance (Han et al., 13 Aug 2025). In yet another setting, it denotes a CPU-DPU machine that must be made to behave like a coherent execution environment through OS- and network-level abstractions (Yang et al., 31 Mar 2025).

A different but related usage appears in analog-mixed-signal inference hardware. The “Cross-Coupling Capacitor Processing Unit” (C3PU) is described as a cross-domain unit because its computation spans the voltage domain for the input sensor signal, the time domain via voltage-to-time conversion, the current domain through CMOS transconductance, and back to the voltage domain at the integrator output (Kilani et al., 2021). This suggests that “cross-domain” in XPU research can refer either to heterogeneous processor domains or to multiple physical signal domains within a single computational primitive.

2. Cross-domain computation in analog-mixed-signal in-memory hardware

The clearest literal “cross-domain” instantiation is C3PU, an analog-mixed-signal in-memory computing MAC engine for AI inference (Kilani et al., 2021). Its central idea is to merge storage and computation in a capacitive cell so that one operand is held as a capacitance ratio while the other is supplied as an analog input converted into a pulse-width signal. A CMOS transistor converts the resulting gate voltage into current, enabling multiply-and-accumulate operations directly in the array (Kilani et al., 2021).

A single C3PU cell contains a capacitive unit, a CMOS transistor, and a voltage-to-time converter. The capacitive unit stores the multiplier operand as an equivalent capacitance ratio,

$X_{eq}=\frac{C_c}{C_c+C_b+C_g},$

and the gate voltage is

$V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$

The transistor then produces

$$I_{ds}=G_m \times V_g =G_m \times V_{in}\frac{C_c}{C_c+C_b+C_g},$$

so the product is represented as current (Kilani et al., 2021). Because the transistor must remain in its linear region, the design uses a voltage-to-time converter whose full-swing output encodes the input as pulse width rather than analog amplitude (Kilani et al., 2021).

The MAC flow is therefore explicitly cross-domain. The stored weight resides in a capacitance ratio; the input voltage is transformed into pulse width; multiplication is realized through capacitor-transistor interaction; and accumulation occurs by summing currents and integrating them to output voltage:

$$V_j=\frac{1}{C_j}\int_{t_1}^{t_2} I_j\,dt =\frac{1}{C_j}\int_{t_1}^{t_2}\sum_{i=1}^{5} I_{ds,ij}\,dt.$$

The paper reports a 5×4 C3PU demonstrator in 65 nm CMOS, operating at 0.3 V, with total energy of 66.4 fJ/MAC and average computation error of 5.7% (Kilani et al., 2021). Compared with a digital 8×4-bit fixed-point MAC in the same technology, the reported figures are 3.4× lower energy and 3.6× smaller area with similar error (Kilani et al., 2021).

The architecture is best suited to fixed-weight inference. The paper explicitly notes constraints including the transistor’s narrow linear region, the required capacitance-ratio range $X_{eq} \approx 0.5 \text{ to } 0.75$, pulse-width degradation with large arrays due to line resistance, and the fact that programmable weights would require memcapacitor-like structures and additional control circuitry (Kilani et al., 2021). Its iris-flower ANN demonstration achieved 90% classification accuracy, compared to 96.67% for the ideal MATLAB ANN (Kilani et al., 2021).

3. XPU as a heterogeneous processor abstraction

In systems literature, XPU usually denotes heterogeneous processing units whose coordination requires explicit abstractions rather than ad hoc device-specific control. The XAUTO runtime for autonomous applications is an example of this usage. It treats CPU, GPU, DLA/NPU-like accelerators, and ASIC-style engines such as VIC and PVA as XPUs, and argues that existing runtime systems such as ROS2, CyberRT, or ERDOS remain module-level and CPU-centric, lacking awareness of fine-grained multi-XPU usage within a single algorithm (Han et al., 13 Aug 2025).

The key abstraction in XAUTO is the XNODE, a stage-level computation unit that can have multiple implementations, one per supported XPU. Its API is $V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$0 where XPU identifies the target processor type, init prepares the implementation and returns a scheduling handle, and exec runs the computation (Han et al., 13 Aug 2025). XNODE boundaries are intended to align with changes in XPU usage. A module is then represented as an XMODULE, which chains multiple XNODEs while managing ordered execution, shared state, and topic-based communication (Han et al., 13 Aug 2025).

The deployment problem is formulated as an ILP over a DAG of XNODEs, with objective $V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$1 to minimize end-to-end latency (Han et al., 13 Aug 2025). The model includes assignment constraints $V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$2 precedence constraints $V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$3 WCET feasibility constraints $V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$4 and a resource-feasibility condition based on demand over each XPU interval (Han et al., 13 Aug 2025). Priorities are then derived from the optimized finish times (Han et al., 13 Aug 2025).

Empirically, the paper reports that XAUTO outperforms ROS2 by 1.23× to 2.01× on synthetic DAGs, with geometric mean improvements of 1.59× on a small configuration and 1.65× on a large configuration (Han et al., 13 Aug 2025). In the “Driving Case” perception pipeline, ROS2 reports 42.0 ms at the 99th percentile, whereas XAUTO reports 26.1 ms, a 1.61× improvement attributed to better XPU placement and fine-grained scheduling (Han et al., 13 Aug 2025). The paper also reports scheduler overheads of about 275 μs for GPU preemption and switch, about 132 μs for DLA preemption and switch, and combined CPU utilization below 0.5% even for 40-node workflows (Han et al., 13 Aug 2025).

This line of work treats XPU as a systems abstraction for heterogeneity rather than a fixed processor family. A plausible implication is that “cross-domain” here refers to transitions between execution domains with distinct performance models, preemption mechanisms, and resource constraints.

4. XPU in cloud-native CPU–DPU systems

A second systems interpretation appears in HeteroPod, where XPU refers to a cross-processing-unit computer spanning CPU and DPU resources (Yang et al., 31 Mar 2025). The motivation is the “infra-burden” of cloud-native systems, in which user containers coexist with infrastructure containers such as sidecar proxies, schedulers, monitors, and mesh components. The paper cites sidecars consuming up to 25% CPU and 33% memory on a node, and reports that sidecars can raise latency by 9.5× to 49.8× depending on workload and load level (Yang et al., 31 Mar 2025).

HeteroPod introduces a dynamic split of Pods across PUs while preserving Pod semantics and supporting unmodified commodity cloud-native applications (Yang et al., 31 Mar 2025). Its enabling substrate, HeteroNet, consists of two mechanisms. The first is a split network namespace, or hetero-netns, which extends Linux network-namespace semantics across PUs. The second is hetero-socket, an elastic and efficient XPU networking mechanism that treats cross-PU interconnects as global shared memory and uses an Interconnect Abstraction Layer to hide whether the underlying channel is RDMA, CXL, or another mechanism (Yang et al., 31 Mar 2025).

The split-namespace design maintains a global reverse mapping table from port numbers to PUs and installs rules using iptables, routing, DNAT, and SNAT so that localhost communication can be transparently forwarded to the correct PU (Yang et al., 31 Mar 2025). For indirect calls, the paper uses partially idempotent packet rules: instead of synchronizing all packet-processing state across PUs, original rules are rewritten into source-side and destination-side rule sets so that redundant actions are permitted when they introduce no new side effects (Yang et al., 31 Mar 2025). The communication substrate also includes speculative allocation, per-core shared arenas, strict access control over shared records, and a user-mode NAPI mechanism with enable_notify_gshm and disable_notify_gshm to reduce polling overhead (Yang et al., 31 Mar 2025).

The paper reports substantial systems-level gains. In microbenchmarks, hetero-socket provides 10.1× better latency for 2 KB messages and up to 31.9× better latency for 16 B messages over baseline Linux networking; for larger messages it provides 2.1× better latency at 256 KB and up to 13.2× at 8 KB (Yang et al., 31 Mar 2025). For 1,000 connections, reserving 16 MB per connection would require 16 GB pinned memory, whereas the OS Overlay uses 128 KB local records plus a 128 MB shared arena, for 256 MB total, summarized as 64× memory saving (Yang et al., 31 Mar 2025). At the application level, the abstract reports up to 60% better end-to-end latency and 55% higher scalability than state-of-the-art systems, while also supporting complex unmodified applications up to 1,085,262 LoC for Python 3.8.10 and 764,457 LoC for Envoy (Yang et al., 31 Mar 2025).

Here again, XPU is a unifying abstraction across processing domains. The emphasis is not arithmetic specialization but preservation of OS, network, and container semantics across CPU–DPU boundaries.

5. XPU performance analysis at machine-code granularity

A third strand concerns XPU as a custom ML accelerator whose production behavior must be analyzed at machine-code granularity. xPU-Shark was introduced to address the limitations of coarse-grained profilers that report only HLO/kernel-level metrics or depend on PMU counters, PC sampling, or binary instrumentation (Zarkadas et al., 18 Mar 2025). Its central idea is to repurpose the accelerator’s Golden Reference Model, originally an ISA-level design simulator, as a record-and-replay performance-analysis engine (Zarkadas et al., 18 Mar 2025).

The system comprises an execution recorder, a replayer, and an analyzer (Zarkadas et al., 18 Mar 2025). During recording, a step debugger attaches to a running accelerator job, sets a breakpoint at a region of interest, and captures a trace by single-stepping through machine code (Zarkadas et al., 18 Mar 2025). The paper emphasizes that traces must come from deployed execution rather than compiler output because control flow, predication, loop trip counts, and memory/register contents are only known at runtime (Zarkadas et al., 18 Mar 2025). To keep traces compact, the recorder maintains sets of seen registers and memory regions,

$R \gets \emptyset,\quad M \gets \emptyset,$

recording a register or memory value only if it has not already been seen (Zarkadas et al., 18 Mar 2025).

Replay occurs in a modified GRM-based ISA-level simulator that restores the architectural state and uses an added performance tracker to collect microarchitectural events such as memory reads, stalls, and compute-unit usage (Zarkadas et al., 18 Mar 2025). The analyzer converts this event stream into actionable views including DMA timelines, instruction-by-instruction utilization, VMEM occupancy and fragmentation analysis, and dynamic dependency tracking (Zarkadas et al., 18 Mar 2025). For dependency analysis, if an instruction reads a value written earlier, xPU-Shark records the dependency and builds a dependency graph. The paper also introduces a relaxed DMA dependency model that propagates dependencies back to the DMA that brought data into VMEM, provided intervening transformations are lightweight (Zarkadas et al., 18 Mar 2025).

The tool revealed several concrete inefficiencies in production LLMs. One class was inefficient DMA scheduling around asynchronous ISSUE and WAIT pairs, with stalls attributable to base latency $T_b$, transfer latency $T_t$, or slack when WAIT arrives after completion (Zarkadas et al., 18 Mar 2025). Another was low compute-unit utilization caused by insufficient data supply from the memory system; in a matrix-multiplication example, MXU idle cycles were correlated with DMA completions and stalls (Zarkadas et al., 18 Mar 2025). A third was VMEM fragmentation: the median unused space was about 47% of total VMEM, but the median contiguous block was only 25% of total capacity, indicating that free space was often fragmented into pieces too small for useful transfers (Zarkadas et al., 18 Mar 2025).

Based on dependency distance and contiguous VMEM availability, the analyzer can recommend DMA reordering or prefetching when

$$push\_limit > stall\_duration \land memory\_available.$$

The broader recommendations include parallelizing independent DMAs, moving DMA setup earlier, pinning small repeatedly used topology metadata in VMEM, and issuing prefetch DMAs sooner when safe (Zarkadas et al., 18 Mar 2025). The reported gains include up to 15% reduction in All-Gather runtime, about 1% end-to-end generation-latency improvement on LLM-Small, about 4.1% on LLM-Medium, and 0.14% on LLM-Big (Zarkadas et al., 18 Mar 2025). In a compute-heavy MXU example, more aggressive prefetching reduced the runtime of that operation by 70% and increased MXU utilization (Zarkadas et al., 18 Mar 2025).

This usage positions XPU as a proprietary accelerator whose behavior must be reconstructed through hardware-faithful simulation rather than generic open-source models. A plausible implication is that “cross-domain” in practice includes the linkage between deployed software traces and hardware-design artifacts.

6. Programming models and scalability across CPU/GPU xPU backends

The term XPU also appears in distributed stencil computing as a portability abstraction over CPU and GPU execution. In “Distributed Parallelization of xPU Stencil Computations in Julia,” xPU means either GPU or CPU, with support for NVIDIA GPUs via [CUDA](https://www.emergentmind.com/topics/kernelbench-cuda).jl, AMD GPUs via AMDGPU.jl, and CPUs within a common framework (Omlin et al., 2022). The package ImplicitGlobalGrid.jl automatically turns code written for one local xPU subdomain into a distributed-memory parallel application (Omlin et al., 2022).

The paper states that “as little as three functions can be enough” to transform a single-xPU stencil code into a massively scaling multi-xPU application: initialize the implicit global staggered grid, perform a halo update, and finalize the global grid (Omlin et al., 2022). The example 3-D heat-diffusion solver uses ParallelStencil.jl with the stencil update $V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$5 and overlaps local computation with halo exchange via $V_g=V_{in}\frac{C_c}{C_c+C_b+C_g}.$6 (Omlin et al., 2022).

The communication layer is built on MPI.jl, typically with a Cartesian MPI communicator. When CUDA-aware MPI or ROCm-aware MPI is available, the framework uses RDMA directly; otherwise it falls back to optimized asynchronous transfers through host memory (Omlin et al., 2022). Pipelining is applied on all stages of the data transfers, and all transfers are performed on non-blocking high-priority streams or queues so that communication can be overlapped optimally with computation (Omlin et al., 2022).

The reported weak-scaling results on Piz Daint are 93% parallel efficiency at 2197 Nvidia Tesla P100 GPUs for the 3-D heat-diffusion solver and over 95% parallel efficiency at 1024 Nvidia P100 GPUs for a nonlinear 3-D poro-visco-elastic two-phase flow solver at a per-GPU problem size of $382^3$ (Omlin et al., 2022). The Julia implementation of the latter solver achieved 90% of the performance of the original CUDA C + MPI solver (Omlin et al., 2022).

This usage differs from the multi-accelerator scheduling and CPU–DPU offloading literature, but it reinforces the same general pattern: XPU denotes an abstraction layer over heterogeneous backends, with performance depending on how communication, memory movement, and concurrency are managed.

7. Conceptual synthesis, misconceptions, and limits of standardization

Across these papers, XPU is best treated as a family resemblance term rather than a formally standardized architecture class. In one branch, it denotes cross-domain analog-mixed-signal computation within a single in-memory MAC primitive (Kilani et al., 2021). In another, it refers to a heterogeneous processor pool requiring explicit stage-level assignment and scheduling (Han et al., 13 Aug 2025). In a third, it denotes a CPU–DPU execution environment whose OS and network abstractions must preserve local semantics across processing units (Yang et al., 31 Mar 2025). In a fourth, it serves as a portability label for CPU/GPU backends in distributed numerical computing (Omlin et al., 2022). And in accelerator-analysis work, it labels custom ML accelerators whose real machine-code behavior must be understood via record-and-replay simulation (Zarkadas et al., 18 Mar 2025).

A common misconception would be to assume that XPU always refers to “GPU plus other accelerators,” or that it names a single hardware ISA or vendor-defined device class. The cited literature does not support that interpretation. Instead, it shows that XPU may refer to CPU/GPU portability (Omlin et al., 2022), to stage-level heterogeneous scheduling across CPU, GPU, DLA, and other engines (Han et al., 13 Aug 2025), to CPU–DPU cloud-native systems (Yang et al., 31 Mar 2025), or to a cross-domain analog unit for in-memory inference (Kilani et al., 2021).

Another misconception would be to assume that all XPU work is primarily about raw compute throughput. Several papers instead show that the governing issues are abstraction design and bottleneck visibility. In xPU-Shark, coarse-grained profilers missed machine-code-level DMA and VMEM inefficiencies, and replay-based analysis enabled concrete optimizations with up to 15% All-Gather improvement and up to 4.1% token-generation latency reduction (Zarkadas et al., 18 Mar 2025). In XAUTO, locally optimal selection of the “fastest” XPU could worsen end-to-end latency through contention, which the ILP-based global model corrected (Han et al., 13 Aug 2025). In HeteroPod, the decisive problem was infra-burden and cross-PU communication semantics, not accelerator arithmetic alone (Yang et al., 31 Mar 2025).

The literature therefore supports a restrained conclusion: XPU is a useful research term for systems or devices that span conventional domain boundaries, but its meaning is context-dependent. This suggests that any precise use of “Cross-Domain Processing Unit” should specify whether the crossing is between signal domains, processor types, runtime stages, or OS-managed processing units.