Gross Code: Bivariate Bicycle Quantum LDPC

• Gross Code is a bivariate bicycle quantum LDPC code with parameters [[144,12,12]], serving as the central target in real-time FPGA decoding studies.
• It utilizes a windowed Relay-BP decoder with dynamic memory belief propagation to achieve 24 ns per BP iteration under strict latency constraints.
• The fully parallel FPGA architecture on an AMD XCVU19P optimizes logical frame updates and resource efficiency for quantum memory experiments.

Searching arXiv for papers on the Gross code, bivariate bicycle quantum LDPC codes, and Relay-BP decoding. The Gross code denotes the $[[144,12,12]]$ bivariate bicycle quantum low-density parity check code that serves as the main target of a real-time FPGA decoding study and is identified there as the code used in the Kookaburra memory experiment. Within that study, the Gross code is treated not merely as a related example but as the central hardware target, situated in the broader family of bivariate bicycle CSS LDPC codes and analyzed through windowed, real-time syndrome decoding based on Relay-BP (Maurer et al., 24 Oct 2025).

1. Code-family placement and named instances

The Gross code belongs to the bivariate bicycle CSS LDPC family. Two named instances are singled out: the Loon $[[56,2,10]]$ code and the Gross $[[144,12,12]]$ code. The latter is the larger instance and the principal focus of the hardware implementation, while the former functions as a smaller companion example. The relationship is explicit: the Gross code is a concrete member of the bivariate bicycle family, and the decoding architecture and performance claims are reported specifically for that member (Maurer et al., 24 Oct 2025).

For the Gross code, the decoder is organized as a windowed decoder acting on a sequence of syndrome cycles. The study fixes the window width to the code distance, $W=12$, and then chooses a runtime-configurable commit width $C$. This coupling of code distance and window size is central to the implementation, because it determines both the temporal extent of the detector window and the latency budget under real-time operation.

Code	Parameters	Role
Loon	$[[56,2,10]]$	Smaller companion code
Gross	$[[144,12,12]]$	Main hardware target

A plausible implication is that the Gross code is being used as a benchmark for decoder architectures aimed at near-term memory experiments on quantum LDPC hardware, rather than only as a purely theoretical code-family instance.

2. Decoding regimes and syndrome representation

The decoding framework treats two regimes: split $XZ$ decoding and full correlated $XYZ$ decoding. In split $XZ$, the syndrome is decomposed into $[[56,2,10]]$0 and $[[56,2,10]]$1, decoded separately with derived check matrices $[[56,2,10]]$2 and $[[56,2,10]]$3, and then combined. In $[[56,2,10]]$4, the full parity-check matrix $[[56,2,10]]$5 and syndrome $[[56,2,10]]$6 are decoded jointly. These two regimes define distinct operating points in the paper’s accuracy–hardware tradeoff analysis, particularly in the precision study (Maurer et al., 24 Oct 2025).

The windowing decoder operates on a sliding-window scheme $[[56,2,10]]$7. For the Gross code, $[[56,2,10]]$8 is fixed, and the decoder extracts a detector window, decodes it, commits corrections in the commit region, and carries boundary information forward via a carried detector correction $[[56,2,10]]$9. This design turns continuous syndrome processing into a bounded-latency sequence of overlapping local decoding tasks.

The hardware discussion associates this windowing discipline with an explicit logical-frame update mechanism. The appendixed algorithm updates the logical Pauli frame through a committed correction and evaluates corrected observables only at the end of the sliding-window process. In operational terms, this separates transient detector corrections from persistent logical-frame bookkeeping.

3. Relay-BP and the dynamic-memory update rule

The decoder algorithm is the recently proposed Relay-BP, built on DMem-BP (dynamic memory belief propagation). Message passing occurs on the Tanner graph $[[144,12,12]]$0 between check nodes and variable or error nodes. The check-to-variable update is

$[[144,12,12]]$1

with sign factor

$[[144,12,12]]$2

The variable-to-check update is

$[[144,12,12]]$3

and the posterior marginal is

$[[144,12,12]]$4

The dynamic-memory bias update is

$[[144,12,12]]$5

where $[[144,12,12]]$6 are the memory strengths. Standard BP appears as the special case $[[144,12,12]]$7. Relay-BP then chains multiple DMem-BP “legs” sequentially: each leg can run for at most $[[144,12,12]]$8 iterations, the relay can have up to $[[144,12,12]]$9 legs, the algorithm stops when it finds $W=12$0 solutions or exhausts the relay, and it returns the lowest-weight solution found. The weight is the LLR-weighted cost

$W=12$1

This structure is significant because it combines min-sum-style local updates with persistent state through $W=12$2, then adds a higher-level restart or chaining mechanism through the relay of DMem-BP legs (Maurer et al., 24 Oct 2025).

4. FPGA realization and fully parallel architecture

The hardware realization is designed for real-time decoding with a fully parallel FPGA architecture. Each variable node and each check node receives its own compute unit, so message traffic is embedded in FPGA wiring rather than stored and routed through centralized memory. The paper emphasizes that each VNU and CNU completes in one FPGA clock cycle; under a flooding schedule, a full BP iteration therefore takes two clock cycles (Maurer et al., 24 Oct 2025).

For the implemented Gross-code decoder, the FPGA clock period is 12 ns, so a full Relay-BP iteration takes 24 ns. This number is central to the real-time claim. A second architectural point is that the CNU does not compute the exact exclusive minimum directly; instead it computes the minimum and second minimum once per check node and passes selector information to the VNU. This reduces logic cost while preserving the min-sum message flow.

The design also uses a min-sum scaling factor

$W=12$3

as an empirical convergence aid. For reduced-precision arithmetic, the study introduces integer formats such as int4.2.8 and a generic scaled integer representation intN.S.M. Memory-strength multiplication is approximated by a shift-and-round style implementation, and for practical values $W=12$4 the decoder reparameterizes with $W=12$5 to simplify hardware. The paper also presents a reduced-logic approximation in which decimal bits are nulled before summing, explicitly as a resource-saving, non-exact multiplier.

5. Runtime, precision, and implementation scale

For the Gross code, the decoder achieves 24 ns per BP iteration. The study states that this is sufficient to keep average decoding time below $W=12$6 per cycle if circuit-level physical error probabilities are below roughly $W=12$7. In the Gross-code memory experiment, under an academic circuit noise model with $W=12$8, Relay-BP-1 converges in fewer than 10 iterations on average, so a 12-cycle window can be decoded in under 240 ns on average; another reported summary states that at $W=12$9, the average iteration count is about 20, implying 480 ns for a full 12-cycle window and an average per-cycle decoding time of 40 ns. The appendix gives a more conservative runtime bound: for a gateware iteration time of 24 ns, a $C$0 sliding-window system can sustain about 333 BP iterations per decoding window while preserving real-time operation (Maurer et al., 24 Oct 2025).

The precision study separates the split and correlated decoding regimes. For the Gross code, 4-bit integer precision plus sign is enough to match floating-point logical error rate for split $C$1 decoding, while 6 bits are needed for comparable performance in correlated $C$2 decoding. The study also notes that 16-, 32-, and 64-bit floating point implementations are essentially identical in logical error rate and iteration count, and that int4 yields substantial hardware savings with little performance loss for $C$3.

The implementation scale on an AMD XCVU19P FPGA is reported as follows:

Resource	Value
Flip-flops	540,767 (6.62%)
LUTs	2,106,738 (51.56%)
LUTRAM	14,052 (1.47%)
BRAMs	29.5 (1.37%)
Total power	58.025 W
User pins	45

The reported balance of resource usage is notable: over half of the available LUTs are consumed, but very little BRAM is needed because messages are stored in the wiring fabric rather than in memory arrays.

6. Nomenclature, scope, and common ambiguities

In the decoding paper, the relationship between the name Gross code and the $C$4 bivariate bicycle code is explicit and repeated. The work is therefore about the Gross code directly, not about a merely adjacent construction or a generic bivariate bicycle decoder (Maurer et al., 24 Oct 2025).

At the same time, the phrase can be confused with unrelated uses of Gross in other research areas. In one-dimensional quantum many-body theory, “Gross” may refer to the Gross–Pitaevskii equation and its non-commutative generalization (Haegeman et al., 2015). In arithmetic geometry and automorphic forms, it may refer to Gross–Zagier and its higher-dimensional or Iwasawa-theoretic generalizations (Zhang, 2024, Howard, 2012). In computational astrophysics, a “Gross code” can denote a code that advances the Gross–Pitaevskii–Poisson system for self-gravitating bosonic matter (Álvarez-Rios, 29 Jun 2026).

A common misconception is therefore terminological rather than mathematical: the Gross code in the quantum error-correction literature is a named bivariate bicycle quantum LDPC code, whereas in these other literatures “Gross” denotes either a differential equation, a formula, or a broader mathematical lineage. The quantum-information usage is unambiguous once the code parameters $C$5, the bivariate bicycle family, and the Kookaburra memory experiment are specified.