Introduction
Pinnacle 1.1 is the latest release of our Pinnacle architecture, focused on efficiently implementing fault tolerance in hardware. It includes a new instantiation of the architecture for superconducting qubits, an explicit compilation for spin qubits, and important new techniques for increasing the logical clock speed of systems with reconfigurable qubits. Pinnacle 1.1 synthesises several advancements we have made in both logic and hardware compilation:
Lifted Surgery is a new technique that accelerates logic in QLDPC codes by up to two orders of magnitude. This significantly reduces the large overhead required to achieve utility-scale quantum computing in slower platforms such as neutral atoms and trapped ions.
Compass is our new software pipeline for hardware compilation. Using Compass, we constructed fast processing blocks using lifted surgery for both neutral atoms and trapped ions.
Frozen Pinnacle is a variant of Pinnacle designed for the fixed connectivity of superconducting qubit hardware. It enables RSA-2048 factoring in one month using 120 thousand qubits, within 25% of Pinnacle 1.0’s 100 thousand qubit reconfigurable architecture.
Silicon Spin Qubit Compilation of a quantum adder to hardware-level operations using the Pinnacle 1.0 design. This validates the feasibility of RSA-2048 factoring with 100 thousand qubits and opens a path to this application on a planned 2029 device.
Pinnacle 1.1 naturally complements and extends Pinnacle 1.0, which focuses on logical and microarchitectural compilation. In Pinnacle 1.0, we showed how to lower high-level quantum algorithms first to a logical instruction set and then to a fault-tolerant microarchitectural circuit specified in terms of physical qubits and abstract physical operations. We focused on these layers because we believe that improvements there are broadly applicable across hardware modalities. Pinnacle 1.1 extends this pipeline into hardware, compiling the microarchitectural circuit into explicit physical operations, and demonstrates that this hardware compilation preserves the architectural improvements achieved at higher levels of the stack.
Pinnacle 1.1 thus marks a significant milestone in developing the end-to-end pipeline needed to power the first applications on a fault-tolerant quantum computer. We believe these advances position Pinnacle for efficient deployment across leading quantum hardware platforms.
Lifted Surgery: Fast Processing
Overview
Atomic platforms are well positioned to achieve utility-scale quantum computation by the end of the decade. Trapped ions have demonstrated two-qubit gate error rates low enough for RSA-2048 factoring with close to 50 thousand qubits using Pinnacle 1.0. Neutral atoms have higher error rates, but significant progress has been shown towards reaching utility-scale on these systems. Both platforms suffer from low physical clock speeds, with cycle times that are one thousand times longer than those of the fastest hardware platforms. This means factoring RSA-2048 with optimal qubit counts would take decades on Pinnacle 1.0. In Pinnacle 1.0 we overcame this through parallelisation across many processing units, at the cost of larger qubit counts. Overcoming the slow speed of these platforms is critical to accelerating their pathway to utility-scale quantum computing.
Lifted surgery is a new technique that reduces the average time per logical operation on Pinnacle by up to two orders of magnitude. It achieves this with qubit overheads comparable to those of Pinnacle 1.0. Lifted surgery preserves the symmetries that make many QEC codes efficiently implementable in hardware. This means that it naturally supports compilation across reconfigurable hardware platforms. We demonstrate this through explicit compilations for both trapped ions and neutral atoms in Section 2. Full integration of lifted surgery into Pinnacle is expected to lead to overhead reductions of one to two orders of magnitude on these platforms, without increasing the architectural complexity.
Results
Lifted surgery allows a logical measurement to be performed in one code cycle (the duration of one round of error correction). The Pinnacle 1.0 instantiations used for RSA-2048 factoring at error rates relevant to neutral atoms and trapped ions require 26 and 18 code cycles per logical measurement, respectively. This is typical of conventional QLDPC code surgery and surface code lattice surgery architectures. In contrast, lifted surgery matches the operation speed of transversal surface code architectures, while maintaining an order-of-magnitude lower space overhead.
Lifted surgery allows for significant parallelism. With k logical qubits per processing block, we can perform up to k parallel logical measurements on a single processing unit per code cycle. For the k = 8 radial codes we have analysed, this gives a peak speedup of approximately 200 times for neutral atoms in circuits supporting maximal parallelism, as shown in Figure 2.
Technical Underpinning
Lifted surgery is an implementation of fast surgery, which we introduced last year. Fast surgery is a form of code surgery, a method for performing logic gates through measurement on quantum information that is encoded in QEC codes. During error correction, the code block is extended by attaching an auxiliary system such that measurements on the auxiliary system implement a logical measurement of the encoded quantum information. To ensure that the encoded information remains protected, surgery must be fault-tolerant. Specifically, it is necessary that the logical measurement outcome is correct even if up to dt/2 individual measurements performed during the surgery are erroneous (where dt is the required time-like distance and is determined by the physical error rate). This necessitates redundancy in the measurements. Conventional surgery achieves this redundancy by repeating the surgery operation dt times. Each surgery round takes one code cycle, and so conventional surgery takes dt code cycles per logical measurement. Fast surgery instead builds redundancy into the auxiliary system through the use of engineered meta-checks on the correctness of the measurements so that a single surgery round is fault-tolerant. This reduces the time per surgery operation — and hence for a full computation — by a factor of dt. For RSA-2048 factoring on Pinnacle 1.0, dt = 18 for trapped ions and dt = 26 for neutral atoms.
Lifted surgery is the first implementation of fast surgery compatible with the low overhead of Pinnacle. It uses a copy of the code block as the auxiliary system. The same checks that allow error correction on the code block are harnessed as the meta-checks in the auxiliary system. This auxiliary system requires fewer qubits than the code block, ensuring it results in low-overhead processing blocks. Attaching this auxiliary system to the code block in different ways allows the measurement of different logical operators of the code. Indeed, for codes with full addressability, such as radial codes, any set of independent logical measurements in the same basis can be performed on the encoded logical qubits in parallel. This is the basis of the fast and parallel surgery that underpins the above results.
Lifted surgery also preserves the underlying symmetries of the code block to which it is applied. This means that the connectivity that must be implemented between qubits of the auxiliary system matches that of the code block. This allows the same types of reconfiguration used for error correction on the code block to be reused for logical measurements using lifted surgery. As a result, well-understood methods for implementing error correction on platforms such as trapped ions and neutral atoms can be leveraged to solve the generally significantly harder challenge of performing logic with code surgery on these platforms, as is demonstrated in Section 2.
Outlook
Lifted surgery allows us to reduce the runtime of applications on reconfigurable hardware platforms by one to two orders of magnitude. This is particularly significant for slow platforms such as trapped ions and neutral atoms. For RSA-2048 factoring with a fixed target runtime, this can be translated into a qubit count reduction on these platforms, by reducing the need for parallelism across many processing units. Lifted surgery can therefore be expected to bring the qubit counts required for RSA-2048 factoring in a feasible runtime on atomic platforms much closer to those required on faster hardware. Combined with the natural compatibility of these platforms with QLDPC codes and the way this compatibility is preserved by lifted surgery, this makes the implementation of Pinnacle enhanced by lifted surgery on such platforms a leading candidate for the first demonstration of utility-scale quantum computation.
While we have focused on slower platforms where the need for faster logic is most pressing, lifted surgery could also be applied to faster reconfigurable platforms such as silicon spin qubits. This suggests that Pinnacle on such a platform could allow millions of logical operations per second, raising the possibility of RSA-2048 factoring in hours with 100 thousand qubits.
Compass: Hardware Compilation Software
Overview
In Pinnacle 1.0 we left open the important problem of how to preserve its low overhead when mapping to real hardware. Hardware platforms impose different connectivity and reconfigurability constraints, meaning that the optimal instantiation of Pinnacle’s modules can vary substantially between platforms. Accurate benchmarking and deployment therefore require a hardware compiler capable of translating microarchitectural circuits into hardware instructions and identifying instantiations that are well matched to the target hardware.
We have developed Compass — a software pipeline designed to address this need. Compass takes as input a microarchitectural module design together with a hardware model that encapsulates the essential connectivity and reconfigurability constraints of a target platform. It outputs a compilation of the module for the specified hardware model, certified to correctly implement the module using only operations permitted by that model. For each compilation, it also outputs a figure of merit that, under appropriate assumptions, quantifies the noise, duration and complexity of the compilation. Compass therefore enables simultaneous compilation and optimisation. It can identify the design best suited to a given hardware model while simultaneously constructing a certified hardware-level implementation of that design.
We have thus far implemented representative models for silicon spin qubits, trapped ions and neutral atoms. Compass has already enabled explicit lifted surgery compilations for trapped ions and neutral atoms, presented below, and identified an optimised code design for silicon spin qubits, presented in Section 4. These results demonstrate how Compass can be used to both verify the hardware compatibility of Pinnacle and to allow its optimisation for specific hardware platforms.
Results
As explained in Section 1, lifted surgery allows for fast, parallel logic to be applied to the logical qubits of a quantum error-correcting code using connectivity that is inherited from the code. As such, it is not fundamentally harder to realise the connectivity required for logic than that required to correct errors in memory. Using Compass, we can quantify the additional hardware cost of lifted surgery and verify that it remains compatible with atomic hardware. Specifically, we use as a test case the [[90,8,10]] radial code. Including the syndrome auxiliary qubits, this gives a code block of 180 qubits; adding the lifted surgery system gives a 315-qubit processing block supporting full addressability.
In the case of trapped ions, we use a hardware model which allows shuttling and nearest-neighbour gates on a 2D grid of sites. The code block can be implemented on a 20 × 15 grid of sites, with syndrome extraction requiring 72 shuttling steps, or an average of 10 per gate layer. The full processing block can be implemented on a 30 × 15 grid of sites, with an example lifted surgery measurement requiring 194 shuttling steps, or an average of 17 per gate layer. The increase reflects the larger spatial extent of the processing block and the interactions between the code block and the auxiliary lifted surgery system. It leaves a total shuttling depth compatible with standard trapped ion noise models. This compilation is shown in Figure 3.
For neutral atoms, we use a hardware model that allows standard acousto-optic deflector (AOD) moves on a 2D grid of sites. Specifically, each AOD move translates a subset of rows or columns in the grid, while preserving their order. Using a design inspired by qSIEVE, the code block can be implemented on a 20 × 89 grid of sites, with syndrome extraction requiring 20 AOD moves with an average translation distance of 26 sites. The full processing block can be implemented on a 20 × 112 grid of sites, with an example lifted surgery measurement requiring 34 AOD moves with an average translation distance of 35 sites. To our knowledge, this is the first explicit compilation of QLDPC surgery to AOD movement primitives. It shows that fast logic can be performed using lifted surgery with AOD movement requirements comparable to those required for syndrome extraction in state-of-the-art QLDPC memories. This compilation is shown in Figure 4.
Technical Underpinning
Compass uses a three-part structure designed to harness AI-powered search and optimisation while nevertheless producing certified and theoretically rigorous results. At its foundation is Theory — a mathematical formalism that defines the quantities of the microarchitectural and hardware layers and their relationships, and from which the figure of merit is derived. Hardware models encapsulating the connectivity and reconfigurability of target hardware platforms are also specified within this Theory. This Theory is then implemented in Software, which acts as the trusted certification layer of Compass. It takes candidate compilations as input and accepts only those that correctly implement the specified module under the specified hardware model. Tooling then provides the exploratory layer, generating candidate compilations across different modules, hardware models and design choices for evaluation by the Software.
This separation is central to the design of Compass. Candidates generated by Tooling are only accepted if certified by the Software layer. Tooling thus serves as a safe environment in which researchers and AI agents can explore and optimise candidate compilations without allowing errors in the Tooling to propagate to invalid outputs. Compass can therefore exploit the effectiveness of AI-powered search and optimisation without making the validity of its results dependent on the reliability of the AI itself.
Outlook
A major open problem left by Pinnacle 1.0 was whether, and at what cost, the architecture could be implemented on different hardware platforms. Compass allows us to answer this question by supporting the optimisation of modules for specific hardware platforms and providing concrete compilations showing how they can be implemented. The lifted surgery compilations presented above, which demonstrate fast, parallel processing blocks on trapped ions and neutral atoms, provide an initial demonstration of this capability. Future versions of Compass will broaden its scope to additional hardware models, including fixed-connectivity platforms such as superconducting qubits.
Going forward, Compass will serve as more than a research and development tool. At full maturity, it will allow for compilation of Pinnacle onto specified hardware platforms on demand. This will provide flexibility to adapt Pinnacle to diverse and evolving hardware through certified benchmarking and compilation.
Frozen Pinnacle: Superconducting Qubit Compatibility
Overview
Superconducting qubits are a leading platform for quantum computing, being pursued by companies such as Google and IBM. They are fabricated as microscopic superconducting electronic circuits on chips and support much faster operations than atomic platforms such as neutral atoms and trapped ions. Their microsecond-scale code cycle time enables RSA-2048 factoring with Pinnacle on one hundred thousand qubit devices in a practical runtime.
The speed of superconducting qubits comes at the cost of flexibility, as their connectivity is fixed by the chip layout. While Pinnacle 1.0 is naturally compatible with atomic platforms that support dynamic reconfiguration of qubits, it does not satisfy the fixed-connectivity constraints of superconducting qubits. In this way, Pinnacle 1.0 is typical of QLDPC architectures, which have historically been regarded as more compatible with atomic platforms than with superconducting qubits.
This release introduces Frozen Pinnacle — our first architecture that is compatible with the fixed connectivity of superconducting qubits.
Results
Frozen Pinnacle allows RSA-2048 factoring in one month with 120 thousand qubits. The increase in qubit count of less than 25% relative to the corresponding Pinnacle 1.0 estimate is remarkably small when compared with alternatives, as shown in Figure 5. Compared with Google’s surface code architecture, it allows factoring with approximately seven times fewer qubits. It also avoids the significant runtime overhead of IBM’s Bicycle Architecture — the previous state-of-the-art fixed-connectivity QLDPC architecture — requiring almost twenty times fewer code cycles to implement the same computation. Frozen Pinnacle is therefore the first architecture to combine the low space overhead of QLDPC architectures with efficient processing under fixed-connectivity constraints.
This result is validated by simulations of the essential operations of Frozen Pinnacle’s modified processing blocks, which are shown in Figure 6. They show that the architecture supports a logical error rate which is significantly lower than that required for RSA-2048 factoring.
Technical Underpinning
The technical core of Frozen Pinnacle is the use of modular efficient gadgets. The modularity of these gadgets means that they have fixed internal connectivity. Their efficiency means that all required operations on a processing block can be implemented using these gadgets. However, implementing the full range of operations requires the gadget to connect to the code block at different locations. In Pinnacle 1.0, this was realised by shifting gadgets’ positions relative to the code block between operations. Such shifts are not compatible with the fixed connectivity constraints of superconducting qubits. Addressing this incompatibility is the central advance of Frozen Pinnacle.
The advance consists of multiple steps. First, we introduce new dual-use modules, in which half of the logical qubits are used as processing qubits and half as memory qubits. Because only the processing qubits need to be fully addressable by gadgets, this reduces the number of movable gadgets required for processing from four to two. We label these the X-type and Z-type gadgets, respectively. The problem is therefore reduced to reproducing, with fixed connectivity, the effect of connecting these two gadgets to the code block at arbitrary relative positions.
This is achieved as follows. A single X-type gadget is connected at a fixed position. Cyclic shift automorphisms are used to reproduce the effect of a shift of the code block relative to this gadget, while maintaining fixed connectivity. Meanwhile, multiple Z-type gadgets — one per processing qubit — are connected in a configuration chosen such that any Z-type operation can be reproduced using a combination of these gadgets, regardless of the cyclic shift applied to the code block. Moreover, to allow for dual use, a further fixed gadget is added to allow read-only access to the memory qubits. To avoid an unacceptable increase in the connectivity of qubits, all of these gadgets are positioned such that no more than two of them touch the code block in any given place.
The result is a fixed-connectivity block that allows for all required processing operations to be performed efficiently, as in Pinnacle 1.0. This avoids the significant time overhead of the Bicycle Architecture, which arises from compiling general computations from a limited instruction set.
One further innovation is the development of a magic engine design specifically optimised for factoring with fixed connectivity. This allows for the size of the magic engine to be reduced relative to the Pinnacle 1.0 magic engine, even while enforcing the fixed-connectivity condition. This is done by preparing an alternative resource state — the CCZ state — that can more efficiently be used to implement the Toffoli gates that underpin factoring than the standard T states used in the original Pinnacle Architecture. Because fewer resource states are required to implement each Toffoli, the magic engine can operate at a lower state-production rate without reducing the computational throughput. This lower required production rate allows the magic engine to be made smaller, reducing its qubit overhead.
Outlook
This result shows the viability of implementing Pinnacle efficiently on superconducting qubits. By demonstrating its compatibility with a hardware platform that is sufficiently fast to support RSA-2048 factoring in a feasible runtime with close to 100 thousand qubits, it corroborates the resource estimates of Pinnacle 1.0.
More generally, the result affirms the strength of Pinnacle’s modular design. Individual modules can be tailored to meet hardware constraints and substituted into the architecture. In this instance, processing blocks and magic engines requiring reconfiguration were replaced, respectively, by fixed-connectivity dual-use modules and CCZ magic engines. This was done while preserving both the underlying components of the architecture (high-rate codes and modular efficient gadgets) and the higher-level structure of the architecture assembled from the modules. This preservation of the core architecture accounts for the small impact on the architecture’s resource requirements. Such modular substitution provides a template for future adaptation to hardware constraints, both foreseen and unforeseen. This adaptability is an intrinsic advantage of Pinnacle’s modular, hardware-agnostic design over architectures tailored to a specific hardware platform.
Silicon Spin Qubits: End-to-End Compilation
Overview
Silicon spin qubit quantum computers possess a combination of features well suited for deployment of Pinnacle. By integrating qubits into silicon chips, they have the potential to achieve speeds competitive with superconducting qubits and orders of magnitude faster than atomic platforms such as trapped ions and neutral atoms. They also support qubit shuttling, providing the reconfigurability required for compatibility with Pinnacle 1.0. Silicon spin qubits therefore have the potential to support utility-scale quantum applications such as RSA-2048 factoring in a feasible runtime with approximately 100 thousand qubits using Pinnacle.
We have explicitly mapped Pinnacle onto a model of Diraq’s planned 2029 silicon spin qubit quantum computer. This confirms that Pinnacle’s modular design is compatible with spin-qubit shuttling constraints at the macroarchitectural level. We have also compiled a quantum adder (a core subroutine of factoring) on Pinnacle’s processing blocks to the level of spin qubit hardware. We have further confirmed the feasibility of this compilation under a hardware-informed noise model. These results yield a resource estimate for RSA-2048 factoring that agrees with that of Pinnacle 1.0 to within 5%.
Results
In mapping the Pinnacle Architecture to spin qubit hardware, the primary consideration is limiting the distance through the chip that any qubit must be shuttled to ensure that speed and fidelity are maintained. Importantly, the modular structure of the Pinnacle Architecture automatically caps the shuttling distance at the scale of a single module, ensuring a workable starting point. Through optimising qubit layouts, circuits and reconfiguration schedules to Diraq’s model hardware, we reduced the required shuttling distance in processing blocks by 35%, at the cost of a 25% increase in qubit overhead. Using Compass, we then developed a quantum error-correcting code tailored for Diraq’s model hardware that further reduced the shuttling distance by 30% on both processing and memory blocks, with no further increase in qubit overhead. Numerical modelling using a hardware-specific noise model that included shuttling predicts that the resulting modules achieve comparable logical error rates to those estimated using the hardware-agnostic noise model of Pinnacle 1.0.
An updated resource estimate using these tailored modules predicts that RSA-2048 factoring could be achieved on this device with 102 thousand qubits, within 5% of the estimate for Pinnacle 1.0. This is well within the 150 thousand qubits of Diraq’s planned 2029 device.
Technical Underpinning
In addition to the numerical analysis referred to above, we also validated compatibility across the stack by combining a macroarchitectural mapping of Pinnacle with an end-to-end compilation of a representative logical circuit on a processing block. This was done in partnership with NVIDIA through early access to their CUDA-Q Logical platform.
As a starting point, we developed a layout of all modules of the architecture (i.e., processing blocks, memory blocks and magic engines) compatible with the macroarchitectural constraints of the hardware. In particular, this mapping verifies that no shuttling beyond the scale of a single module is required in any code cycle. This justified performing further analysis at the level of individual modules.
We then focused on a processing block as the core module of interest. Specifically, we used CUDA-Q Logical to instantiate such a block. We logically compiled an example adder circuit to obtain the sequence of logical measurement operations executed on this processing block in its implementation. We then microarchitecturally compiled each of these logical measurement operations to produce microarchitectural circuits which fault-tolerantly implement them. Each of these circuits consisted of a sequence of physical qubit operations that implement a syndrome extraction circuit on a merged code block and auxiliary measurement system.
We then performed hardware compilation of each of these circuits to a model of Diraq’s silicon spin qubit hardware. This produced a specification of the layout of spin qubits and a schedule of shuttling operations and physically implementable operations (such as gates between adjacent qubits) that executes each microarchitectural circuit on the processing block. This compilation allows for benchmarking through the direct computation of metrics such as shuttling distances. More broadly, it amounts to a set of hardware-level instructions for performing the logical circuit on the processing block. Extending this process across all modules of the architecture and all parts of the factoring algorithm will produce a complete hardware-level specification for implementing factoring on spin qubit hardware using Pinnacle.
Outlook
These results lay the foundation for RSA-2048 factoring on a spin qubit device planned for release this decade. They directly show that factoring-relevant logical circuits on Pinnacle can be compiled to such a device. They also show that the resource estimate performed for Pinnacle 1.0 is largely unchanged by the hardware constraints of this platform. This is particularly significant, since the fast operation speed of spin qubits means that factoring with approximately 100 thousand qubits could be achieved in a feasible runtime, making this a practically relevant capability rather than merely a theoretical one.
More generally, the end-to-end compilation serves as a model for future compilation to other hardware platforms. The logical and microarchitectural compilations we have performed are hardware-independent, meaning that this portion of the work is reusable across platforms. Using Compass, tailored hardware compilations can then be performed for each target platform. Extending this workflow will therefore provide a foundation for deploying Pinnacle across hardware platforms.
Conclusion
In this release, we have addressed the compilation of Pinnacle down to hardware-level operations. We have demonstrated that silicon spin qubits can support RSA-2048 factoring with close to 100 thousand qubits using Pinnacle. This is supported by end-to-end compilation of a representative factoring-relevant logical circuit to this hardware. We have also overcome the primary obstacle to deployment of Pinnacle on superconducting qubits through the development of Frozen Pinnacle, which is compatible with fixed-connectivity constraints. This enables hardware compilation for superconducting qubits while retaining a qubit count for RSA-2048 factoring only marginally above the 100 thousand qubit estimate of Pinnacle 1.0. Finally, we have developed lifted surgery as a method for reducing processing times by up to two orders of magnitude. This provides a route to overcoming the primary obstacle to low-overhead factoring with neutral atoms or trapped ions — the infeasible runtime at low qubit counts. We have also verified the feasibility of this solution by using our optimisation and compilation software, Compass, to demonstrate explicit hardware compilation of lifted surgery to these platforms.
We believe these results provide the foundation for the deployment of Pinnacle across four leading hardware platforms: silicon spin qubits, superconducting qubits, neutral atoms and trapped ions. They show that all of these platforms support a path to RSA-2048 factoring with qubit counts comparable to the estimate of 100 thousand qubits presented in Pinnacle 1.0. Future releases will build on this to further improve the resource estimates and to ensure Pinnacle is ready for deployment on the first generation of utility-scale quantum computers.