QuCtrl-BELL: Compiler-Driven Quantum Control

• QuCtrl-BELL is a compiler-driven software stack that decouples control flow from hardware state, enabling deterministic sub-700 ns feedback for trapped-ion experiments.
• Its pure-Python DSL and six-stage compilation pipeline convert high-level control constructs into efficient, board-loadable binaries while maintaining modularity.
• Benchmark results show significant hardware record compression and fixed latency performance, supporting scalable deployment on RISC-V and PXIe architectures.

Searching arXiv for the primary paper and closely related control-stack literature. QuCtrl-BELL, usually abbreviated Bell, is a compiler-driven software stack for trapped-ion quantum control designed to reconcile two requirements that are often treated as antagonistic: sub-microsecond board-level feedback through tight hardware coupling, and maintainability and extensibility through clean, modular software abstractions. Bell resolves this tradeoff by decoupling control flow—including loops, branches, and synchronization—from hardware state data, and lowering a Python-embedded domain-specific language through a six-stage transpilation pipeline to deterministic distributed board-level programs and compact step-table data. It is deployed on the QuCtrl-BELL platform, a RISC-V + PXIe system, where a cross-board synchronization protocol supports feedback loops with latency below $700~\mathrm{ns}$ without host intervention (She et al., 21 May 2026).

1. Hardware organization and execution model

Bell is implemented on a 9-slot JYTEK PXIe chassis housing DDS/AWG boards for coherent RF tone generation, TTL/TDC boards for gate signals and photon counting, and a TCM (Trigger Clock Manager) module that provides star-topology clock and data broadcast (She et al., 21 May 2026). Each board embeds a local RISC-V core, a small step-table memory, and a 250 MHz system clock, which yields 4 ns step granularity. The boards communicate through two distinct interconnects: the PXIe backplane, used for high-speed PCIe transfers of code and step tables, and the TCM star bus, used for low-latency broadcast for synchronization, with latency reported as $<100~\mathrm{ns}$.

A central architectural distinction is between the Control Program and the Step Table. The Control Program is a compact sequence of RISC-V and custom instructions encoding loops, branches, synchronization barriers, and reads. The Step Table is an array of hardware-state records containing DDS frequency/amplitude/phase, TTL masks, and step duration; instructions refer to these records by index. This split is not merely organizational. It defines the execution model of the stack.

Compilation occurs on the host, which emits per-board control binaries and step tables. At runtime, the hardware preloads these artifacts via PCIe, after which the RISC-V cores enter a lock-step execution driven purely by board logic, with no host involvement on the critical timing path (She et al., 21 May 2026). The result is a distributed controller in which determinism is a property of the generated board programs and board-to-board synchronization protocol rather than of host-side scheduling.

2. Programming model and Python-embedded DSL

Bell’s front end is a pure-Python API exposing three layers: channel and state, sequence, and variable (She et al., 21 May 2026). At the lowest layer, Device objects represent individual DDS or TTL channels, while State objects bundle multiple channels into a named multi-channel configuration. This provides a direct representation of the physical control surface without requiring the user to manipulate board binaries or hardware-state records explicitly.

At the sequence level, Bell exposes structured control-flow constructs through context managers. The API includes seq.loop(N) for fixed-count loops, seq.if_(cond), seq.else_(), and seq.while_(cond) for branching, and seq.barrier(), seq.wait(), and seq.resume() for explicit synchronization semantics. Hardware operations are interleaved with control flow through the | operator, as in expressions such as seq | Cool(1000) | Repump(5000), and photon counting is represented by seq.read_ttl(pmt).

The variable layer is defined by typed, host-opaque variables that live entirely on the board. Loop counters and read results therefore remain in board-resident state rather than being materialized through host communication. Comparisons such as counts < threshold become board-native branches. The paper’s feedback example places a detection operation and a TTL read inside a loop of 20 iterations, then conditionally performs repumping and cooling if the measured count is below 5. In Bell, that logic is compiled directly into board-level control flow rather than emulated through host callbacks. This programming model is the software expression of the paper’s broader claim that feedback, branching, and synchronization should be first-class compilation targets rather than ad hoc firmware features (She et al., 21 May 2026).

3. Six-stage compilation pipeline

Bell lowers the DSL through six explicit intermediate representations, each of which is inspectable for debugging (She et al., 21 May 2026). This compiler structure is a defining property of the system, because the paper positions Bell not as a macro assembler or template expander but as a full control compiler.

Stage	Core operation	Output
1	Node Tree Construction from Python AST	Typed node tree with source locations
2	CFG Construction	Precise control-flow graph
3	SSA Conversion	SSA-form CFG with $\phi$-functions
4	Liveness Analysis & Interference Graph	Live ranges and interference graph
5	Graph-Coloring Register Allocation	Register-annotated CFG
6	Backend Code Generation & Step-Table Encoding	Board-loadable binaries and step-table files

The first stage constructs a typed node tree with source locations from the Python AST. The second stage builds a control-flow graph (CFG) in which sequential nodes remain in a basic block, seq.loop introduces a back-edge, and seq.if_ creates branch and merge blocks. This CFG becomes the substrate for standard data-flow analysis.

In the third stage, Bell performs Static Single Assignment (SSA) conversion using the standard dominance-frontier method. At merge points, $\phi$-functions are inserted so that each variable is written exactly once:

$v_B = \phi(v_{P_1}, v_{P_2}, \ldots)$

where $P_i$ are the predecessors of $B$. The fourth stage computes liveness by backward data flow:

$$\mathrm{live\_out}[b] = \bigcup_{s \in \mathrm{succ}(b)} \mathrm{live\_in}[s]$$

$$\mathrm{live\_in}[b] = \mathrm{use}[b] \cup (\mathrm{live\_out}[b] \setminus \mathrm{def}[b])$$

and builds an interference graph $G=(V,E)$, where $<100~\mathrm{ns}$0 is the set of SSA variables and $<100~\mathrm{ns}$1 when $<100~\mathrm{ns}$2 and $<100~\mathrm{ns}$3 are live at the same point.

The fifth stage applies graph-coloring register allocation with a simplify/spill heuristic. The paper states a sufficient no-spill condition as $<100~\mathrm{ns}$4, by Brooks’ theorem, where $<100~\mathrm{ns}$5 is the target register count. If spills are required, Bell inserts spill code, with loop-carried variables prioritized to avoid hot-path stalls. The backend then emits 32 bit RISC-V + custom instructions for control flow, arithmetic, step-index operations, and read_ttl synchronization primitives, together with the per-board step tables (She et al., 21 May 2026).

4. Control-flow/data separation and distributed feedback

A core design principle of Bell is that “control” (loops/branches/sync) is separate from “data” (DDS/TTL parameters) (She et al., 21 May 2026). The paper attributes three direct benefits to this control-flow versus hardware-state decoupling.

First, it improves compactness. Repeating a $<100~\mathrm{ns}$6-step waveform $<100~\mathrm{ns}$7 times uses $<100~\mathrm{ns}$8 table entries plus loop instructions, not $<100~\mathrm{ns}$9 hardware records. The paper gives a quantitative example for an “Active feedback” program with $\phi$0 iterations over $\phi$1 distinct hardware states: a naive inline representation requires $\phi$2 hardware records, whereas the Bell step table uses 6 records plus a small loop/branch instruction stream, yielding a 20× reduction.

Second, it enables parametric reuse. For sweeps over a parameter $\phi$3, only the step table must be regenerated, while the control program remains identical. Third, it supports modularity, because the control-program format never changes across backends; only the backend code generator must be adapted. These properties are presented as structural rather than incidental: Bell’s compiler is designed around the idea that execution structure and device-state payload should evolve independently.

This same separation underlies Bell’s support for fast distributed feedback. The primitive read_ttl is implemented as a 4-phase, compile-time-fixed sequence: Barrier, TTL Read, Broadcast Release, and Branch Resolve. During the barrier, all boards execute a custom sync instruction and stall at step $\phi$4. The TTL board then performs a local read with $\phi$5, broadcasts the count over the TCM star bus with $\phi$6, and all boards simultaneously resolve the branch. The total feedback latency is expressed as

$\phi$7

The paper further states that $\phi$8 is a single-cycle custom instruction, $\phi$9 is 2–3 RISC-V cycles, and the measured end-to-end latency is $\phi$0, specifically CH2 detection falling edge to CH4 feedback rising edge = 690 ns (She et al., 21 May 2026).

5. Performance characteristics and scaling behavior

The evaluation reported for Bell covers compilation, runtime latency, memory usage, and hardware growth (She et al., 21 May 2026). For six benchmark programs, end-to-end compilation completes in $\phi$1 wall time. The paper states that individual pipeline stage costs are single-digit ms even for complex loops and nested feedback, that assembly sizes remain in the tens of instructions, and that register allocation never spills for the tested benchmarks.

At runtime, Bell distinguishes between feedback-free and feedback-bearing sequences. “Feedback-free” sequences run asynchronously ahead of wall-clock time with negligible overhead. By contrast, each read_ttl invocation incurs a fixed $\phi$2 latency that is described as fully deterministic across boards. The emphasis on fixed latency is significant: Bell is not merely minimizing average control delay but compiling to a distributed execution regime in which latency is predictable and synchronized.

Memory behavior follows from the step-table architecture. The paper states that step-table entries scale only with distinct hardware states $\phi$3, not total iterations $\phi$4. In a nested-loop sweep with $\phi$5 and $\phi$6, a naive representation requires 4000 records, whereas Bell uses 4 records, giving 1000× compression. This is one of the clearest quantitative demonstrations of the consequences of decoupling control flow from hardware-state data.

Hardware scaling is described in concrete chassis-level terms. A single 9-slot chassis supports up to 24 DDS channels + 32 TTL channels, and expansion beyond that is said to be linear in additional chassis & TCM modules. The compiler’s backend is also described as modular, so that it can target new FPGA or RFSoC boards without altering front- or middle-ends (She et al., 21 May 2026). This suggests a separation not only between control flow and state data, but also between the language/middle-end and the final hardware target.

6. Position within quantum-control software

Bell is explicitly positioned against several prior control systems in the paper’s comparative table (She et al., 21 May 2026).

System	Characterization in the paper	Feedback / compilation profile
ARTIQ/Sinara	latency $\phi$7	no full compiler pipeline; no control/data separation
QubiC	partial parametric feedback	limited control-flow compilation
QICK	macro-ASM	limited branching support
Bell	full CFG/SSA/RA pipeline	explicit control/data decoupling; $\phi$8 board-level feedback

This comparison is framed around a recurring systems question in quantum control: whether fast feedback necessarily requires collapsing software abstractions into board-specific firmware. Bell’s answer is architectural rather than rhetorical. The stack uses CFG construction, SSA conversion, liveness analysis, and graph-coloring register allocation—all recognizably compiler-theoretic mechanisms—while still targeting deterministic board-level execution with sub-microsecond feedback. The paper’s broader conclusion is that a compiler-based infrastructure can provide programmability, deterministic timing, and modularity for scalable trapped-ion quantum control (She et al., 21 May 2026).

A plausible implication is that Bell treats classical control for trapped-ion experiments as a compilation problem with hardware-timed semantics, rather than as a collection of host scripts and board-local special cases. On that reading, its contribution is not only the measured $\phi$9 feedback path, but also the claim that structured control flow, explicit synchronization, and target modularity can coexist in a single stack for scalable trapped-ion experiments.