High-Throughput Normalized Min-Sum Belief Propagation Decoding for Quantum LDPC Codes with Near-Memory Processing

Quantum Low-Density Parity-Check (qLDPC) codes have attracted significant attention as a promising approach to reducing the physical qubit overhead of large-scale fault-tolerant quantum computation [4, 5, 14]. Compared with conventional two-dimensional local topological codes such as the surface code, qLDPC codes can support higher encoding rates while maintaining sparse parity-check structures [13, 4, 14]. In a qLDPC code, each physical qubit participates in a limited number of stabilizer checks, and each check acts on a limited number of qubits, resulting in a bounded-degree sparse connectivity structure [4].

The parity-check structure of a qLDPC code can be represented as a Tanner graph [7]. A Tanner graph is a bipartite graph composed of variable nodes and check nodes, where variable nodes represent physical qubits or error variables and check nodes represent stabilizer measurements or parity constraints. An edge indicates that the corresponding variable participates in a particular check. Figure 1 shows the Tanner-graph structure of the $[[144,12,12]]$ Bivariate Bicycle (BB) qLDPC code considered in this work [14]. The sparse connectivity of this graph limits each node update to information from a small set of neighboring nodes, providing a natural structure for iterative message-passing decoding [6, 11].

Belief Propagation (BP) exploits this sparse Tanner-graph representation by iteratively exchanging reliability messages between neighboring variable and check nodes [6, 7, 11, 15]. The decoder begins by assigning each variable node an initial reliability based on the physical error probability, typically represented by a log-likelihood ratio (LLR) [16, 17]. Variable nodes send reliability messages to their neighboring check nodes, and each check node combines the incoming messages with the measured syndrome to enforce the corresponding parity constraint [6, 16]. The resulting check-to-variable messages are returned to the variable nodes and combined with the channel prior to update the posterior reliability. A hard decision is then obtained from the updated reliability values, and the message-passing procedure is repeated over successive BP iterations [16, 17].

The sparse Tanner graph makes individual BP updates dependent only on neighboring nodes and therefore exposes fine-grained parallelism in the message-update process [4, 11]. At the same time, iterative BP decoding retains edge-associated messages and node reliabilities and repeatedly accesses and updates this state over successive iterations. The resulting workload combines sparse arithmetic with repeated memory accesses, and its processing cost increases with the number of Tanner-graph edges and BP iterations. In a fault-tolerant system where syndrome instances are generated and decoded continuously, the same message-passing workload is executed repeatedly across many independent syndrome instances. These characteristics make memory locality and parallel processing capacity important architectural considerations for high-throughput qLDPC BP decoding.

Iterative BP decoding repeatedly accesses message state and node reliabilities while exposing parallelism across local message updates and independent syndrome instances. For such workloads, frequent transfers through a conventional processor-memory hierarchy can make data movement an important component of execution cost [8, 30]. Near-Memory Processing (NMP) provides an architectural approach in which computation is performed close to memory, allowing frequently accessed data to remain near the processing units [32]. In this work, near-memory processing refers to this execution principle, while DPU-based Processing-in-Memory (PIM) denotes the concrete architecture used to realize it. UPMEM-PIM provides a programmable PIM platform in which lightweight processing cores, referred to as Data Processing Units (DPUs), are integrated with DRAM and execute kernels using DPU-local memory resources [9, 19, 31].

Figure 2 illustrates the DPU-based PIM architecture considered in this work. The host CPU performs application-level control and transfers programs and data to PIM-enabled DIMMs through the memory interface, while the DPUs execute data in parallel kernels [9, 19, 20]. The system configuration consists of 20 double-ranked PIM DIMMs. Each rank contains eight PIM chips, and each PIM chip contains eight DPUs, yielding a total of $20\times 2\times 8\times 8=2,560$ DPUs [9, 18, 19, 20]. Independent data partitions can therefore be processed concurrently across a large number of DPUs, providing system-level parallelism.

Each DPU contains an in-order processing pipeline and several local memory structures [9, 18, 19, 21]. IRAM stores instructions, WRAM provides software-managed storage for frequently accessed working data, and MRAM provides a larger local DRAM space for input and output data. Data are transferred between MRAM and WRAM through DMA operations [9, 18, 19]. A DPU supports up to 24 hardware threads, referred to as tasklets, which share the processing pipeline and local memory resources [9, 19]. Instructions from different tasklets are interleaved through fine-grained multithreading, and consecutive instructions from the same tasklet follow the 11-cycle revolver scheduling constraint [19]. The number of active tasklets and the distribution of work among them therefore influence utilization of the shared DPU pipeline.

The local memory hierarchy and large-scale DPU parallelism are well aligned with the repeated data accesses and independent syndrome-level workloads of qLDPC BP decoding. These architectural properties provide the basis for near-memory execution aimed at high-throughput BP decoding.

Real-time quantum error correction requires the classical decoder to process syndrome information at a rate compatible with the QEC cycle and to provide correction information or Pauli-frame updates within the timing requirements of fault-tolerant control [40, 43]. The available decoding time depends on the underlying qubit technology and control architecture. Trapped-ion platforms generally operate with longer gate and measurement timescales than superconducting platforms and are commonly associated with a correspondingly longer decoder timing budget [38, 39]. This millisecond-scale regime provides a relevant timing context for evaluating high-throughput qLDPC decoding.

Recent decoder studies provide concrete references for this timing regime. AlphaQubit identifies a target decoding time of approximately $1~\mathrm{ms}$ per QEC round for trapped-ion devices, compared with approximately $1~\mu\mathrm{s}$ per round for superconducting qubits [41]. More directly for qLDPC decoding, the beam-search decoder for the $[[144,12,12]]$ Bivariate Bicycle code evaluates the 99.9th-percentile runtime per-syndrome extraction round and identifies a configuration with a runtime below $1~\mathrm{ms}$ as a promising candidate for trapped-ion architectures [12]. Based on these studies, $1~\mathrm{ms}$ is adopted in this work as a decoder-side timing reference for evaluating the BP compute stage. The reported DPU latency represents the serialized $X+Z$ decoder-kernel computation associated with a single syndrome instance, providing a consistent reference for comparing decoder execution time with the millisecond-scale timing regime.

Real-time operation also depends on the distribution of decoding completion times. Occasional long-running decoding instances can delay the availability of correction information and contribute to a backlog of pending syndrome data even when typical execution times remain within the target range [33, 40]. Tail latency therefore provides an important complement to aggregate throughput and average processing time when evaluating a decoder for real-time QEC. Percentile-based latency and the maximum sampled completion time are consequently useful for characterizing whether decoder execution remains predictable under repeated syndrome processing.

Standard log-domain Belief Propagation (BP) computes check-to-variable messages using nonlinear functions such as $\tanh$ and $\mathrm{atanh}$ [6, 16, 23]. Normalized Min-Sum BP provides a reduced-complexity formulation of BP by replacing the nonlinear magnitude computation in the check-node update with sign evaluation, minimum-magnitude selection, and normalization [24, 25, 26, 27, 29]. Its primary check-node operations can consequently be expressed using comparisons, additions, sign operations, and fixed-point scaling. The UPMEM-based DPU architecture used in this work employs an integer-oriented execution pipeline, while floating-point operations are supported through software routines [9, 19]. This execution model is well aligned with the arithmetic structure of normalized Min-Sum BP, allowing its reduced-complexity message updates to be implemented primarily with integer operations supported by the DPU. Based on this combination of algorithmic efficiency and architectural compatibility, normalized Min-Sum BP is used as the decoding algorithm in the proposed DPU-based execution scheme.

Figure 4 compares the arithmetic structures of standard log-domain BP and normalized Min-Sum BP from the DPU execution perspective. The normalized Min-Sum implementation used in this work fixes the normalization factor to $\alpha=0.75=3/4$. With this value, the normalization step in the fixed-point implementation can be expressed using integer addition and bit shifting.

Let $m_{v\rightarrow c}$ denote the message from variable node $v$ to check node $c$, and let $m_{c\rightarrow v}$ denote the message in the opposite direction. Let $N(c)$ and $N(v)$ denote the neighboring variable and check nodes of $c$ and $v$, respectively. For a measured syndrome value $s_{c}$, the normalized Min-Sum check-node update is expressed as

The sign of the outgoing message is determined by the syndrome value and the signs of the incoming messages. Its magnitude is obtained from the minimum incoming magnitude excluding the target variable node and is then scaled by the normalization factor $\alpha$. The normalization factor compensates for the tendency of the basic Min-Sum approximation to overestimate check-node reliability [24, 25, 26, 28, 29]. For the fixed value $\alpha=3/4$, scaling a non-negative magnitude (a) is implemented as $((a\ll 1)+a)\gg 2$, before the message sign is applied. The normalization operation is therefore represented using integer addition and bit-shift operations in the DPU kernel.

The variable-node update combines the channel prior $L_{v}$ with incoming check-to-variable messages:

The decoder uses a row-layered normalized Min-Sum schedule with a running posterior reliability $\lambda_{v}$. At initialization,

Before check node $c$ is updated, its previous contribution is removed from the running posterior:

After $m_{c\rightarrow v}^{\mathrm{new}}$ is computed, the check-to-variable message and running posterior are updated in place:

The row-layered schedule immediately incorporates each newly computed check-node message into the running posterior, allowing the updated reliability information to be used by subsequent check-node updates within the same BP iteration. In the proposed implementation, the message state and posterior reliability are therefore updated in place throughout the iterative decoding process.

The check-to-variable messages and running posterior values are represented as signed 32-bit integers during decoding. After the final BP iteration, the posterior value is clipped as

and stored as a signed 16-bit integer. The estimated error component is obtained from the sign of the posterior reliability:

These design choices provide an arithmetic-level match between normalized Min-Sum BP and the UPMEM-based DPU execution model. The check-node update is expressed through sign operations, minimum selection, addition, and bit shifting. The layered schedule updates reliability information in place, and the iterative decoding state is represented using integer data types. Together, these properties form the computational basis for executing normalized Min-Sum BP on the DPU architecture.

For each $X$- or $Z$-error decoding, one DPU processes one syndrome instance. Figure 5 shows the overall processing flow within a DPU. The host CPU transfers the syndrome data to DPU MRAM, and the working data required for iterative normalized Min-Sum BP decoding are then loaded into WRAM. During decoding, the message values and posterior reliabilities stored in WRAM are repeatedly updated over the specified number of BP iterations. After the iterations are completed, the posterior output is stored in MRAM and transferred back to the host.

The memory organization follows the repeated data access pattern of iterative BP decoding. MRAM is used mainly for data transfer between the host and the DPU, while the syndrome, check-to-variable messages, and running posterior reliabilities are maintained in WRAM during decoding. These values are repeatedly read and updated by the row-layered normalized Min-Sum schedule. Keeping this intermediate state in DPU-local WRAM allows the decoder to reuse the same data throughout successive BP iterations. Data transfers between MRAM and WRAM are performed through DMA operations, following the local-memory organization of UPMEM-based DPUs [9, 19, 20].

With the repeatedly accessed decoding state maintained in WRAM, the check-node computations for one syndrome are divided among 11 tasklets within the DPU. The tasklets use the same DPU processing pipeline and access the shared decoding state in WRAM while processing different subsets of check nodes. In the UPMEM-based DPU architecture, instructions from different tasklets are interleaved through fine-grained multithreading, and consecutive instructions from the same tasklet are separated by the 11-cycle revolver scheduling constraint [9, 19]. The proposed implementation uses 11 tasklets to partition the check-node computations of the same syndrome across the shared DPU pipeline.

Applying this tasklet-level parallelism to the row-layered update requires the shared-data dependencies to be handled explicitly. Processing a check node $c$ updates the running posterior reliability $\lambda_{v}$ of each variable node connected to that check. If two check nodes share a variable node, simultaneous processing would cause both checks to update the same $\lambda_{v}$. We therefore define two check nodes $c_{i}$ and $c_{j}$ as conflicting when

For the $[[144,12,12]]$ Bivariate Bicycle qLDPC code used in this work, the 72 check nodes are divided into three conflict-free color groups, $\mathcal{G}_{1}$, $\mathcal{G}_{2}$, and $\mathcal{G}_{3}$. Check nodes assigned to the same group have non-overlapping variable-node neighborhoods:

Each variable node in this Tanner graph is connected to three check nodes. The three check nodes connected to the same variable therefore belong to different color groups so that no two checks within a group share that variable. The three-group partition used in the proposed decoder satisfies this condition for the fixed Tanner graph. As a result, check nodes within the same group update different posterior values and can be processed concurrently without write conflicts.

During decoding, the check nodes in one color group are distributed across the 11 tasklets. Each tasklet performs normalized Min-Sum updates for its assigned check nodes using the message and posterior data stored in WRAM. After all tasklets complete the processing of the group, a barrier synchronizes them before the next group begins. The next color group then uses the posterior reliabilities updated by the preceding group. In this way, check nodes within each color group are processed in parallel, while synchronization between groups preserves the update order of the row-layered normalized Min-Sum schedule.

Beyond the workload partitioning within each DPU, independent syndrome instances are distributed across multiple DPUs. In the 2,560-DPU configuration considered in this work, each DPU processes one syndrome instance, allowing independent decoding workloads to proceed concurrently without cross-DPU synchronization during BP computation [9, 19]. This DPU-level syndrome parallelism provides the system-scale processing capacity used to increase aggregate decoding throughput.

The CPU baseline is evaluated on an Amazon EC2 m4.4xlarge instance equipped with an Intel Xeon E5-2686 v4 processor running at $2.30~\mathrm{GHz}$. The instance provides 16 logical CPUs, corresponding to eight physical cores with two hardware threads per core. The CPU decoder is compiled with GCC 11.4.0 in an Ubuntu Linux environment. DPU execution is evaluated using uPIMulator, which provides DPU logical cycle counts while modeling tasklet scheduling and the revolver pipeline constraint. The simulated cycle counts are converted to execution time using a $350~\mathrm{MHz}$ DPU clock frequency [9, 19]. The decoding experiments target the $[[144,12,12]]$ Bivariate Bicycle (BB) qLDPC code [14]. To characterize decoder behavior under different physical error conditions, five component-wise physical error probabilities are considered:

For each data qubit, the $X$- and $Z$-error components are introduced independently with probability $p$. The resulting single qubit Pauli probabilities are

For each $X$- or $Z$-component error vector $e$, the corresponding syndrome is determined from the parity-check matrix (H) as

No measurement errors are added during syndrome extraction. The syndrome is determined by the generated data qubit error pattern and the parity-check structure. The $X$- and $Z$-error components are decoded separately, and one complete decoding trial consists of one $X$-component decode and one $Z$-component decode. For each component, the estimated correction $\hat{e}$ is combined with the generated error to obtain the residual error,

A component decode is considered successful when the estimated correction reproduces the input syndrome and the residual error belongs to the corresponding stabilizer row space. A complete $X+Z$ trial is recorded as a logical failure when either component decode fails. The logical error rate (LER) is evaluated for BP iteration counts from 1 to 10, with a fixed iteration count applied to all trials in each configuration. For each physical error probability and iteration count, 10 independent runs are performed using different random seeds, with $10^{7}$ complete $X+Z$ trials in each run. This provides $10^{8}$ trials per configuration and sufficient failure observations in the low-LER regime considered in this work. The LER is estimated from the observed fraction of logical failures. Since this estimate is obtained from a finite number of success-or-failure outcomes, Wilson 95% confidence intervals are reported to quantify its statistical uncertainty.

CPU throughput is measured using 50,000 complete $X+Z$ decoding trials for each physical error probability and BP iteration count. A fixed number of trials is used for every configuration to maintain the same workload size across throughput measurements. The 16 logical CPUs process independent syndrome instances in parallel. Each configuration is measured 10 times using different random seeds, and throughput is reported as the mean number of complete decoding trials processed per second. For DPU throughput, uPIMulator provides the cycle count for one $X$- or $Z$-component decoding pass using the proposed 11-tasklet configuration. A complete decode consists of sequential $X$- and $Z$-component passes, and the corresponding processing time is obtained from the simulated cycle counts at $350~\mathrm{MHz}$. Cycle counts are collected for 10 independently generated syndrome inputs. Because the syndrome workloads assigned to different DPUs use independent decoding state and require no inter-DPU synchronization during BP decoding, the 2,560-DPU configuration is represented as concurrent execution of independent DPU decoding tasks. The per-DPU cycle counts provided by uPIMulator are used to determine the system throughput under this concurrent-execution model [9, 19, 20]. The reported DPU metrics characterize decoder-kernel execution, which is evaluated at the cycle level using uPIMulator. Host–DPU data transfer and runtime orchestration are treated as separate system stages, consistent with the full-system organization of UPMEM-based execution in which data movement between the host and PIM modules constitutes a distinct part of the execution path [20]. This stage-separated evaluation provides a consistent basis for characterizing the computation and parallel processing capacity of the proposed decoding kernel.

Single syndrome tail latency is evaluated for BP iteration counts from 1 to 5. For the CPU baseline, $10^{7}$ complete $X+Z$ decoding times are collected for each configuration. This sample count provides approximately $10^{4}$ observations within the upper $0.1\%$ of the measured distribution, allowing the $p99.9$ latency region to be characterized from a sufficiently populated set of observations. For the DPU, the latency distribution is obtained from $10^{4}$ independently seeded uPIMulator runs. The serialized $X+Z$ latency is calculated from the simulated DPU cycle counts. The distributions are summarized using the mean, standard deviation, $p50$, $p90$, $p99$, $p99.9$, and the maximum sampled latency.

Before collecting the performance results, the DPU decoding program executed in uPIMulator is verified against the CPU reference decoder. Both decoders receive the same syndrome input and use the same fixed-point channel prior, normalization factor, row-layered update order, and BP iteration count. Their posterior outputs are compared byte by byte, and all configurations reported in this work satisfy this output-equivalence check. Formal definitions of throughput, per-syndrome processing time, tail latency, and LER are provided in Appendix A.1.

Figure 6 compares the decoding throughput of the 16-logical-CPU baseline and the 2,560-DPU configuration at $p=0.001$ as the number of BP iterations increases. The comparison represents the processing capacity of the two evaluated configurations. The CPU baseline processes independent syndrome instances across 16 logical CPUs, while the DPU configuration processes independent syndrome instances concurrently across 2,560 DPUs.

The 2,560-DPU configuration provides higher throughput than the CPU baseline across all evaluated iteration counts. At one BP iteration, the CPU baseline processes approximately $1.22\times 10^{6}$ complete decodes/s, while the 2,560-DPU configuration reaches approximately $1.071\times 10^{7}$ complete decodes/s, corresponding to an $8.8\times$ difference. At ten iterations, the throughput decreases to approximately $1.93\times 10^{5}$ complete decodes/s for the CPU baseline and $1.55\times 10^{6}$ complete decodes/s for the DPU configuration, which corresponds to an $8.0\times$ difference. Thus, the configuration-level throughput advantage is maintained as the BP workload increases with the iteration count.

The higher throughput of the DPU configuration is primarily associated with syndrome-instance-level parallelism across the DPU array. Each DPU uses 11 tasklets to process the check-node workload of one syndrome instance, while different DPUs process different syndrome instances independently. The 11 tasklets within a DPU therefore contribute to the execution of the same decoding task, whereas system-level throughput is increased by executing many independent decoding tasks concurrently across 2,560 DPUs. This workload organization matches the parallel execution characteristics reported for UPMEM systems, where independent data partitions can be distributed across multiple DPUs with minimal inter-DPU communication [9, 18]. The throughput difference in Figure 6 therefore reflects the large degree of syndrome-level parallelism available in the DPU configuration rather than a direct comparison between the computational performance of one DPU and one CPU core.

Throughput decreases on both configurations as the BP iteration count increases. Under the fixed-iteration row-layered schedule, each additional iteration repeats the check-node message calculations and variable-node reliability updates over the Tanner graph, increasing the amount of computation required for each syndrome [16, 17]. This relationship is directly reflected in the DPU execution cost. At $p=0.001$, the simulated cycle count for one component increases from 41,815 cycles at one iteration to 289,760 cycles at ten iterations, an increase of approximately $6.9\times$. Over the same range, the 2,560-DPU throughput decreases from $1.071\times 10^{7}$ to $1.55\times 10^{6}$ complete decodes/s, also by approximately $6.9\times$. The throughput reduction therefore follows the increase in the computation required to complete each syndrome as additional BP iterations are performed.

The physical error probability has a substantially smaller effect on throughput than the iteration count under the evaluated fixed-iteration execution. Changing $p$ changes the generated error and syndrome patterns, while the decoder still traverses the same Tanner-graph structure and executes the same sequence of row-layered message-update stages for a fixed number of iterations. Consequently, the DPU cycle counts and throughput remain nearly constant across the evaluated physical error probabilities at a given iteration count. The CPU throughput also shows considerably smaller variation with $p$ than with the BP iteration count. These results show that, under the fixed-iteration decoding scheme used in this work, the throughput is governed primarily by the number of BP iterations and the available syndrome-instance parallelism. The detailed numerical results supporting these observations are provided in Table 1 of Appendix A.2.

Figure 7 compares the logical error rate (LER) and per-syndrome DPU processing time as the number of BP iterations increases. The LER is evaluated for the five physical error probabilities considered in this work, while the processing time represents the compute time required to complete the serialized $X$- and $Z$-component decoding passes. The results exhibit a clear trade-off. Increasing the BP iteration count improves decoding performance, while each additional iteration increases the compute time required for one syndrome.

As a reference for decoding performance, we consider the break-even condition $p_{L}(p)<p$, where $p_{L}(p)$ denotes the measured LER at physical error probability $p$. At one iteration, this condition is satisfied for $p=0.001$, with an LER of $3.628\times 10^{-4}$. For the remaining physical error probabilities, the one-iteration LER remains above the corresponding value of $p$. From two iterations onward, the condition is satisfied for all evaluated physical error probabilities.

The largest LER reduction occurs during the first few BP iterations. From one to two iterations, the LER decreases by approximately $49.7\times$ at $p=0.001$ and $13.6\times$ at $p=0.009$. The incremental improvement then becomes smaller: from two to three iterations, the LER decreases by approximately $2.2$–$2.4\times$ across the evaluated values of $p$. At $p=0.001$, it reaches approximately $3.1\times 10^{-6}$ after three iterations and remains near this level, whereas at $p=0.009$ it decreases more gradually from $1.8829\times 10^{-3}$ at three iterations to $1.4334\times 10^{-3}$ at ten iterations.

This behavior follows the iterative message-propagation and convergence characteristics of loopy BP [34, 35]. During the early iterations, syndrome information is propagated through check-to-variable messages and repeatedly incorporated into the posterior reliabilities. Under the row-layered schedule, updated information from preceding layers is also available to subsequent layers within the same iteration. These early message-passing rounds can therefore produce substantial changes in variable reliabilities and hard decisions [16, 17]. As the iterations continue, the posterior reliabilities of converging instances become progressively more stable, reducing the effect of subsequent message updates. The remaining failures also increasingly consist of error configurations that are difficult for standard BP to resolve through additional iterations alone. In qLDPC codes, short cycles and quantum degeneracy can interfere with BP convergence [11, 36, 37], which is consistent with the diminishing LER improvement observed after the first few iterations.

In contrast to the diminishing LER improvement, the per-syndrome DPU processing time increases almost linearly with the BP iteration count. The processing time is approximately $0.239~\mathrm{ms}$ at one iteration, $0.397~\mathrm{ms}$ at two iterations, $0.556~\mathrm{ms}$ at three iterations, and $0.872~\mathrm{ms}$ at five iterations, reaching approximately $1.656~\mathrm{ms}$ at ten iterations. Consecutive iteration settings add approximately $0.157$–$0.159~\mathrm{ms}$ of complete $X+Z$ processing time. This behavior follows directly from the fixed-iteration execution structure. Early termination is not applied, and each additional iteration repeats the same row-layered check-node calculations, reliability updates, and color-group synchronization sequence over the fixed Tanner graph. The amount of additional computation introduced by each iteration is therefore nearly constant, producing the approximately linear increase in processing time observed in Figure 7.

Taken together, these results establish a clear trade-off between LER and per-syndrome processing time. Each additional BP iteration incurs an approximately constant compute-time cost, while the corresponding LER reduction becomes progressively smaller after the first few iterations. This trade-off is particularly pronounced at lower physical error probabilities, where most of the observed LER improvement is obtained with relatively few iterations. At higher physical error probabilities, additional iterations continue to provide measurable LER improvement over a wider iteration range, although the marginal improvement gradually decreases. From the processing time perspective, five iterations require approximately $0.872~\mathrm{ms}$, while six iterations increase the value to approximately $1.029~\mathrm{ms}$. The evaluated one-to-five-iteration range therefore remains within the $1~\mathrm{ms}$ decoder-side compute-time reference considered in this work. These results characterize the BP iteration count as a direct parameter for balancing decoding performance and per-syndrome processing time. Detailed numerical results for the LER and per-syndrome DPU processing time are provided in Table 1 of Appendix A.2.

Figure 8 compares the single syndrome latency distributions of the CPU baseline and the DPU configuration at five BP iterations for $p=0.001$ and $p=0.009$. The distributions are characterized using $p50$, $p90$, $p99$, $p99.9$, and the maximum sampled latency, since high-percentile latency is important for identifying infrequent decoding delays that may not be visible from the average execution time alone [33]. The DPU values represent the serialized $X+Z$ compute-only latency obtained from simulated DPU cycle counts.

The CPU baseline exhibits substantially lower latency over most of the distribution. As shown in Figure 8, the CPU $p50$, $p90$, and $p99$ values remain far below the $1~\mathrm{ms}$ reference for both physical error probabilities. The upper tail, however, increases sharply. The $p99.9$ latency approaches the reference, and the maximum sampled latency exceeds $1~\mathrm{ms}$ for both $p=0.001$ and $p=0.009$. This difference between typical and extreme execution times shows that a low median or average latency alone does not fully characterize the timing behavior relevant to real-time decoding.

The DPU latency distribution shows a different behavior. At five iterations, the simulated mean latency is $869.260~\mu\mathrm{s}$ for $p=0.001$ and $857.161~\mu\mathrm{s}$ for $p=0.009$. For $p=0.001$, the median and the reported upper percentiles are approximately $871.543~\mu\mathrm{s}$. For $p=0.009$, the median is $853.560~\mu\mathrm{s}$, while $p90$ through the maximum remain at or below approximately $872.606~\mu\mathrm{s}$. The corresponding standard deviations are $5.843~\mu\mathrm{s}$ and $7.759~\mu\mathrm{s}$, respectively, both below $1\%$ of the mean latency. The distribution is therefore concentrated within a narrow timing range, and all reported percentiles and maximum sampled values remain below the $1~\mathrm{ms}$ decoder-side reference.

The different tail behaviors are consistent with the execution characteristics of the two platforms. CPU BP decoding repeatedly accesses sparse Tanner-graph messages and posterior information through the CPU memory hierarchy, so its execution time can be affected by cache behavior, memory-bandwidth utilization, and data movement through the hierarchy. The CPU environment also includes system-level scheduling effects that can contribute to occasional long execution times. In the simulated DPU execution, the decoding kernel follows a fixed iteration count and a largely deterministic sequence of row-layered updates and color-group synchronization. The DPU pipeline modeled by uPIMulator also operates without conventional CPU caches or operating-system scheduling inside the DPU. These properties reduce input-dependent cycle-count variation in the evaluated simulation and are consistent with the narrow DPU latency distribution observed in Figure 8.

The five-iteration result represents the highest processing time within the one-to-five-iteration range emphasized in the tail-latency evaluation. Across all evaluated physical error probabilities and BP iteration counts from one to five, the maximum sampled serialized $X+Z$ DPU compute latency remains below $1~\mathrm{ms}$, with the largest observed value reaching approximately $0.873~\mathrm{ms}$ at five iterations. Thus, within the evaluated simulation conditions, the DPU configuration maintains predictable sub-millisecond decoder-kernel latency throughout this iteration range. The reported DPU values characterize decoder-side compute time, which refers host–DPU communication and runtime-management stages are treated separately from this latency metric.