<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
      <title>Iceberg Quantum</title>
      <link>https://www.iceberg-quantum.com</link>
      <description>Designing the Next Generation of Fault-Tolerant Quantum Computing Architectures.</description>
      <generator>Zola</generator>
      <language>en</language>
      <atom:link href="https://www.iceberg-quantum.com/rss.xml" rel="self" type="application/rss+xml"/>
      <lastBuildDate>Tue, 22 Sep 2026 00:00:00 +0000</lastBuildDate>
      <item>
          <title>Pinnacle 1.1</title>
          <pubDate>Tue, 22 Sep 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/pinnacle-1-1/</link>
          <guid>https://www.iceberg-quantum.com/blog/pinnacle-1-1/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/pinnacle-1-1/">&lt;p&gt;We&#39;re releasing Pinnacle 1.1.&lt;/p&gt;
&lt;p&gt;It documents our progress in closing the gap between high-level architecture and practical implementation on leading hardware platforms.&lt;/p&gt;
&lt;p&gt;Read the release &lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/&quot;&gt;here&lt;/a&gt;.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Pinnacle 1.1</title>
          <pubDate>Tue, 22 Sep 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/releases/pinnacle-1-1/</link>
          <guid>https://www.iceberg-quantum.com/releases/pinnacle-1-1/</guid>
          <description xml:base="https://www.iceberg-quantum.com/releases/pinnacle-1-1/">&lt;h2 id=&quot;introduction&quot;&gt;Introduction&lt;/h2&gt;
&lt;p&gt;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:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#lifted-surgery&quot;&gt;&lt;strong&gt;Lifted Surgery&lt;/strong&gt;&lt;/a&gt; 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.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#compass&quot;&gt;&lt;strong&gt;Compass&lt;/strong&gt;&lt;/a&gt; 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.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#frozen-pinnacle&quot;&gt;&lt;strong&gt;Frozen Pinnacle&lt;/strong&gt;&lt;/a&gt; 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.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#silicon-spin-qubits&quot;&gt;&lt;strong&gt;Silicon Spin Qubit Compilation&lt;/strong&gt;&lt;/a&gt; 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.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Pinnacle 1.1 naturally complements and extends &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2602.11457&quot;&gt;Pinnacle 1.0&lt;/a&gt;, 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;div class=&quot;release-figure&quot; role=&quot;figure&quot; aria-labelledby=&quot;pinnacle-1-1-fig1-caption&quot;&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;pinnacle-1-1-fig1&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;pinnacle-1-1_fig01_layers@3x.webp&quot; alt=&quot;The different layers of Pinnacle&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;&lt;script defer src=&quot;pinnacle-1-1_fig01_layers.js&quot;&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figcaption&quot; id=&quot;pinnacle-1-1-fig1-caption&quot;&gt;
&lt;p&gt;&lt;strong&gt;Figure 1:&lt;/strong&gt; The different layers of Pinnacle. End-to-end compiling maps from the algorithm layer to the hardware layer through three compilation stages.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;h2 id=&quot;lifted-surgery&quot;&gt;Lifted Surgery: Fast Processing&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://www.iceberg-quantum.com/blog/lifted-surgery/&quot; class=&quot;release-publication&quot;&gt;Associated publication&lt;svg aria-hidden=&quot;true&quot; width=&quot;12&quot; height=&quot;12&quot; viewBox=&quot;0 0 12 12&quot; fill=&quot;none&quot;&gt;&lt;path d=&quot;M3.5 8.5l5-5M4.5 3.5h4v4&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;1.2&quot;/&gt;&lt;/svg&gt;&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&quot;lifted-surgery-overview&quot;&gt;Overview&lt;/h3&gt;
&lt;p&gt;Atomic platforms are well positioned to achieve utility-scale quantum computation by the end of the decade. Trapped ions have demonstrated &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2510.17286&quot;&gt;two-qubit gate error rates&lt;/a&gt; low enough for RSA-2048 factoring with close to 50 thousand qubits using Pinnacle 1.0. Neutral atoms have higher error rates, but &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2403.12021&quot;&gt;significant progress has been shown&lt;/a&gt; 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.&lt;/p&gt;
&lt;p&gt;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 &lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#compass&quot;&gt;Section 2&lt;/a&gt;. 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.&lt;/p&gt;
&lt;h3 id=&quot;lifted-surgery-results&quot;&gt;Results&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Lifted surgery allows for significant parallelism. With &lt;span class=&quot;math&quot;&gt;&lt;em&gt;k&lt;/em&gt;&lt;/span&gt; logical qubits per processing block, we can perform up to &lt;span class=&quot;math&quot;&gt;&lt;em&gt;k&lt;/em&gt;&lt;/span&gt; parallel logical measurements on a single processing unit per code cycle. For the &lt;span class=&quot;math&quot;&gt;&lt;em&gt;k&lt;/em&gt; = 8&lt;/span&gt; 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.&lt;/p&gt;
&lt;div class=&quot;release-figure&quot; role=&quot;figure&quot; aria-labelledby=&quot;pinnacle-1-1_fig02_measurement-time-rate-caption&quot;&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;&quot; data-src=&quot;pinnacle-1-1_fig02_measurement-time-rate.json&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;pinnacle-1-1_fig02_measurement-time-rate@3x.webp&quot; alt=&quot;Logical measurement time and rate comparison&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figcaption&quot; id=&quot;pinnacle-1-1_fig02_measurement-time-rate-caption&quot;&gt;
&lt;p&gt;&lt;strong&gt;Figure 2:&lt;/strong&gt; Time per logical measurement and maximum logical measurement rate for Pinnacle 1.0 with neutral atoms and trapped ions, compared with lifted surgery. Both platforms are assumed to have a code cycle time of one millisecond and time-like distances of &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt; = 26&lt;/span&gt; and &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt; = 18&lt;/span&gt;, corresponding to those for RSA-2048 factoring on Pinnacle 1.0. The maximum logical measurement rate denotes the maximum number of logical measurements that can be performed per second. This represents the theoretical peak operation rate for optimal circuits and should not be assumed to always be achievable.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;h3 id=&quot;lifted-surgery-technical-underpinning&quot;&gt;Technical Underpinning&lt;/h3&gt;
&lt;p&gt;Lifted surgery is an implementation of &lt;a href=&quot;https://www.iceberg-quantum.com/blog/fast-surgery/&quot;&gt;fast surgery&lt;/a&gt;, which we introduced last year. Fast surgery is a form of &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.science.org/doi/10.1126/sciadv.abn1717&quot;&gt;code surgery&lt;/a&gt;, 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 &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt;/2&lt;/span&gt; individual measurements performed during the surgery are erroneous (where &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt;&lt;/span&gt; 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 &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt;&lt;/span&gt; times. Each surgery round takes one code cycle, and so conventional surgery takes &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt;&lt;/span&gt; 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 &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt;&lt;/span&gt;. For RSA-2048 factoring on Pinnacle 1.0, &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt; = 18&lt;/span&gt; for trapped ions and &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;sub&gt;&lt;em&gt;t&lt;/em&gt;&lt;/sub&gt; = 26&lt;/span&gt; for neutral atoms.&lt;/p&gt;
&lt;p&gt;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 &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2406.14445&quot;&gt;radial codes&lt;/a&gt;, 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.&lt;/p&gt;
&lt;p&gt;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 &lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#compass&quot;&gt;Section 2&lt;/a&gt;.&lt;/p&gt;
&lt;h3 id=&quot;lifted-surgery-outlook&quot;&gt;Outlook&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h2 id=&quot;compass&quot;&gt;Compass: Hardware Compilation Software&lt;/h2&gt;
&lt;h3 id=&quot;compass-overview&quot;&gt;Overview&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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 &lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#silicon-spin-qubits&quot;&gt;Section 4&lt;/a&gt;. 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.&lt;/p&gt;
&lt;h3 id=&quot;compass-results&quot;&gt;Results&lt;/h3&gt;
&lt;p&gt;As explained in &lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#lifted-surgery&quot;&gt;Section 1&lt;/a&gt;, 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.&lt;/p&gt;
&lt;p&gt;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 &lt;span class=&quot;math&quot;&gt;20 × 15&lt;/span&gt; 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 &lt;span class=&quot;math&quot;&gt;30 × 15&lt;/span&gt; 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.&lt;/p&gt;
&lt;div class=&quot;release-figure&quot; role=&quot;figure&quot; aria-labelledby=&quot;pinnacle-1-1-fig3-caption&quot;&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;pinnacle-1-1-fig3&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;pinnacle-1-1_fig03_trapped-ion@3x.webp&quot; alt=&quot;Trapped ion lifted surgery animation&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;&lt;script defer src=&quot;pinnacle-1-1_fig03_trapped-ion.js&quot;&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figcaption&quot; id=&quot;pinnacle-1-1-fig3-caption&quot;&gt;
&lt;p&gt;&lt;strong&gt;Figure 3:&lt;/strong&gt; Implementation of a lifted surgery measurement of four logical operators in parallel on the [[90,8,10]] radial code on a trapped ion hardware model. Each circle represents a site, with filled circles representing qubits. Lines between qubits represent CNOT gates.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;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 &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2311.16980&quot;&gt;qSIEVE&lt;/a&gt;, the code block can be implemented on a &lt;span class=&quot;math&quot;&gt;20 × 89&lt;/span&gt; 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 &lt;span class=&quot;math&quot;&gt;20 × 112&lt;/span&gt; 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 &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2607.28795&quot;&gt;state-of-the-art QLDPC memories&lt;/a&gt;. This compilation is shown in Figure 4.&lt;/p&gt;
&lt;div class=&quot;release-figure&quot; role=&quot;figure&quot; aria-labelledby=&quot;pinnacle-1-1-fig4-caption&quot;&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;pinnacle-1-1-fig4&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;pinnacle-1-1_fig04_neutral-atom@3x.webp&quot; alt=&quot;Neutral atom lifted surgery animation&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;&lt;script defer src=&quot;pinnacle-1-1_fig04_neutral-atom.js&quot;&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figcaption&quot; id=&quot;pinnacle-1-1-fig4-caption&quot;&gt;
&lt;p&gt;&lt;strong&gt;Figure 4:&lt;/strong&gt; Implementation of a lifted surgery measurement of four logical operators in parallel on the [[90,8,10]] radial code on a neutral atom hardware model. Each circle represents a site, with filled circles representing qubits. Lines between qubits represent CNOT gates.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;h3 id=&quot;compass-technical-underpinning&quot;&gt;Technical Underpinning&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id=&quot;compass-outlook&quot;&gt;Outlook&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h2 id=&quot;frozen-pinnacle&quot;&gt;Frozen Pinnacle: Superconducting Qubit Compatibility&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://arxiv.org/pdf/2609.21249&quot; class=&quot;release-publication&quot; target=&quot;_blank&quot; rel=&quot;noopener&quot;&gt;Associated publication&lt;svg aria-hidden=&quot;true&quot; width=&quot;12&quot; height=&quot;12&quot; viewBox=&quot;0 0 12 12&quot; fill=&quot;none&quot;&gt;&lt;path d=&quot;M3.5 8.5l5-5M4.5 3.5h4v4&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;1.2&quot;/&gt;&lt;/svg&gt;&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&quot;frozen-pinnacle-overview&quot;&gt;Overview&lt;/h3&gt;
&lt;p&gt;Superconducting qubits are a leading platform for quantum computing, being pursued by companies such as &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://quantumai.google/quantumcomputer&quot;&gt;Google&lt;/a&gt; and &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.ibm.com/quantum/hardware&quot;&gt;IBM&lt;/a&gt;. 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This release introduces Frozen Pinnacle — our first architecture that is compatible with the fixed connectivity of superconducting qubits.&lt;/p&gt;
&lt;h3 id=&quot;frozen-pinnacle-results&quot;&gt;Results&lt;/h3&gt;
&lt;p&gt;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 &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2505.15917&quot;&gt;Google’s surface code architecture&lt;/a&gt;, it allows factoring with approximately seven times fewer qubits. It also avoids the significant runtime overhead of &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2506.03094&quot;&gt;IBM’s Bicycle Architecture&lt;/a&gt; — 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;div class=&quot;release-figure&quot; role=&quot;figure&quot; aria-labelledby=&quot;pinnacle-1-1_fig05_space-time-overhead-caption&quot;&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;&quot; data-src=&quot;pinnacle-1-1_fig05_space-time-overhead.json&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;pinnacle-1-1_fig05_space-time-overhead@3x.webp&quot; alt=&quot;Comparison of space and time overhead&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figcaption&quot; id=&quot;pinnacle-1-1_fig05_space-time-overhead-caption&quot;&gt;
&lt;p&gt;&lt;strong&gt;Figure 5:&lt;/strong&gt; Comparison of space and time overhead for Google’s surface code architecture, IBM’s Bicycle Architecture and Frozen Pinnacle. Space overheads are calculated for a device with the required processing and memory qubits for factoring. Only the &lt;span class=&quot;math&quot;&gt;&lt;em&gt;p&lt;/em&gt;&lt;sub&gt;&lt;em&gt;L&lt;/em&gt;&lt;/sub&gt; ≤ 10&lt;sup&gt;−15&lt;/sup&gt;&lt;/span&gt; case suffices for RSA-2048 factoring, but higher error rates are shown for comparison since no instantiation of the Bicycle Architecture has been presented for this regime. Numbers presented are indicative estimates, extrapolated from existing numbers where necessary, and should be treated as approximations.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figure&quot; role=&quot;figure&quot; aria-labelledby=&quot;pinnacle-1-1_fig06_logical-error-rate-caption&quot;&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;&quot; data-src=&quot;pinnacle-1-1_fig06_logical-error-rate.json&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;pinnacle-1-1_fig06_logical-error-rate@3x.webp&quot; alt=&quot;Frozen Pinnacle logical error rate performance&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figcaption&quot; id=&quot;pinnacle-1-1_fig06_logical-error-rate-caption&quot;&gt;
&lt;p&gt;&lt;strong&gt;Figure 6:&lt;/strong&gt; Performance of the Frozen Pinnacle Architecture, which corresponds to the &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt; = 24&lt;/span&gt; points of this plot. Shift and Bridged Measurement, respectively, represent the two essential operations that enable efficient computation on the architecture.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figure&quot; role=&quot;figure&quot; aria-labelledby=&quot;pinnacle-1-1-fig7-caption&quot;&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;pinnacle-1-1-fig7&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;pinnacle-1-1_fig07_resources@3x.webp&quot; alt=&quot;Pinnacle 1.0 and Frozen Pinnacle resource comparison&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;&lt;script defer src=&quot;pinnacle-1-1_fig07_resources.js&quot;&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;div class=&quot;release-figcaption&quot; id=&quot;pinnacle-1-1-fig7-caption&quot;&gt;
&lt;p&gt;&lt;strong&gt;Figure 7:&lt;/strong&gt; Comparison of Pinnacle 1.0, which allows for RSA-2048 factoring with approximately 100 thousand qubits (100 kq) in one month, and Frozen Pinnacle, which allows factoring with approximately 120 thousand qubits (120 kq) in the same time while maintaining fixed connectivity.&lt;/p&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;h3 id=&quot;frozen-pinnacle-technical-underpinning&quot;&gt;Technical Underpinning&lt;/h3&gt;
&lt;p&gt;The technical core of Frozen Pinnacle is the use of &lt;a href=&quot;https://www.iceberg-quantum.com/blog/modular-and-efficient-surgery/&quot;&gt;modular efficient gadgets&lt;/a&gt;. 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This is achieved as follows. A single X-type gadget is connected at a fixed position. &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.nature.com/articles/s41586-024-07107-7&quot;&gt;Cyclic shift automorphisms&lt;/a&gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id=&quot;frozen-pinnacle-outlook&quot;&gt;Outlook&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h2 id=&quot;silicon-spin-qubits&quot;&gt;Silicon Spin Qubits: End-to-End Compilation&lt;/h2&gt;
&lt;p&gt;&lt;a href=&quot;https://www.iceberg-quantum.com/blog/working-with-nvidia-and-diraq/&quot; class=&quot;release-publication&quot;&gt;Associated publication&lt;svg aria-hidden=&quot;true&quot; width=&quot;12&quot; height=&quot;12&quot; viewBox=&quot;0 0 12 12&quot; fill=&quot;none&quot;&gt;&lt;path d=&quot;M3.5 8.5l5-5M4.5 3.5h4v4&quot; stroke=&quot;currentColor&quot; stroke-width=&quot;1.2&quot;/&gt;&lt;/svg&gt;&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&quot;silicon-spin-qubits-overview&quot;&gt;Overview&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;We have explicitly mapped Pinnacle onto a model of &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.diraq.com/s/The-case-for-silicon.pdf&quot;&gt;Diraq’s planned 2029 silicon spin qubit quantum computer&lt;/a&gt;. 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%.&lt;/p&gt;
&lt;h3 id=&quot;silicon-spin-qubits-results&quot;&gt;Results&lt;/h3&gt;
&lt;p&gt;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 &lt;a href=&quot;https://www.iceberg-quantum.com/releases/pinnacle-1-1/#compass&quot;&gt;Compass&lt;/a&gt;, 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id=&quot;silicon-spin-qubits-technical-underpinning&quot;&gt;Technical Underpinning&lt;/h3&gt;
&lt;p&gt;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 &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://nvidianews.nvidia.com/news/nvidia-expands-open-source-cuda-q-platform-for-fault-tolerant-quantum-computing&quot;&gt;partnership with NVIDIA&lt;/a&gt; through early access to their &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://developer.nvidia.com/cuda-q&quot;&gt;CUDA-Q&lt;/a&gt; Logical platform.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h3 id=&quot;silicon-spin-qubits-outlook&quot;&gt;Outlook&lt;/h3&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;h2 id=&quot;conclusion&quot;&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Working with NVIDIA and Diraq</title>
          <pubDate>Mon, 14 Sep 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/working-with-nvidia-and-diraq/</link>
          <guid>https://www.iceberg-quantum.com/blog/working-with-nvidia-and-diraq/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/working-with-nvidia-and-diraq/">&lt;p&gt;&lt;em&gt;Joint announcement&lt;/em&gt;&lt;/p&gt;
&lt;h3 id=&quot;iceberg-quantum-and-diraq-confirm-pinnacle-s-logical-advantage-for-spin-qubits-using-nvidia-cuda-q-logical&quot;&gt;Iceberg Quantum and Diraq Confirm Pinnacle’s Logical Advantage for Spin Qubits Using NVIDIA CUDA-Q Logical&lt;/h3&gt;
&lt;p&gt;Today we&#39;re announcing work done by Iceberg Quantum and Diraq, leveraging early access to the &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://nvidianews.nvidia.com/news/nvidia-expands-open-source-cuda-q-platform-for-fault-tolerant-quantum-computing&quot;&gt;newly announced&lt;/a&gt; Logical layer of the NVIDIA CUDA-Q platform. The work demonstrated how Iceberg Quantum’s Pinnacle architecture can be implemented on Diraq&#39;s spin-qubit hardware platform while preserving Pinnacle&#39;s logical performance advantage.&lt;/p&gt;
&lt;p&gt;It is often assumed that quantum low-density parity-check (QLDPC) architectures such as Pinnacle require significantly more complex quantum hardware than the surface code. This work shows that need not be the case. Pinnacle can be implemented on Diraq&#39;s hardware without demanding significantly more of the platform than a standard surface code approach.&lt;/p&gt;
&lt;p&gt;The result is that the first version of Pinnacle enables Diraq to achieve a target 1,000 logical qubits with just 150,000 physical qubits, as reported in Diraq’s white paper, &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://static1.squarespace.com/static/68b8f22a905c77127b4ebab0/t/6a6ae3a1779dbf141080a1a9/1785389985792/The+case+for+silicon.pdf&quot;&gt;`The Case for Silicon`&lt;/a&gt;. Future versions of Pinnacle will continue to boost the logical efficiency of Diraq’s devices further.&lt;/p&gt;
&lt;h4 id=&quot;mapping-pinnacle-to-diraq-s-hardware&quot;&gt;Mapping Pinnacle to Diraq’s hardware&lt;/h4&gt;
&lt;p&gt;To establish this result, we embedded Pinnacle within Diraq&#39;s hardware architecture. We specified how physical qubits should be allocated, identified the exact codes that would be used, and showed how to generate the required connectivity by shuttling qubits around the array. In short, everything you need to compile logical circuits on Pinnacle down to physical operations on hardware.&lt;/p&gt;
&lt;p&gt;The key design challenge was implementing Pinnacle&#39;s non-local connectivity while keeping shuttling distances small, since qubits accumulate errors as they are shuttled. Because Pinnacle is built from modular processing blocks, non-local connectivity is only ever needed within a block, never across the whole device. We then optimised the codes, circuits and shuttling schedules within each block so that shuttling contributes no more to the error budget than other sources, such as physical gates.&lt;/p&gt;
&lt;p&gt;The result was that physical qubit counts from the &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2602.11457&quot;&gt;Pinnacle paper&lt;/a&gt; agree with hardware-aware estimates on Diraq&#39;s hardware to within 5%, and numerical simulations including shuttling-dependent noise verified logical performance suitable for useful quantum computing. The takeaway is that it is possible to implement Pinnacle on spin qubits whilst maintaining its low overhead and logical performance.&lt;/p&gt;
&lt;h4 id=&quot;a-cross-stack-collaboration&quot;&gt;A cross-stack collaboration&lt;/h4&gt;
&lt;p&gt;NVIDIA CUDA-Q Logical allowed us to specify the full path from logical circuits in Pinnacle to physical operations on Diraq&#39;s hardware. With this new layer in the CUDA-Q platform we were able to demonstrate end-to-end compilation of important logical primitives, such as adder circuits, down to the hardware level. The CUDA-Q platform can then also generate full-stack resource estimates for different combinations of logical algorithms and target devices, without rebuilding the compilation machinery.&lt;/p&gt;
&lt;p&gt;“This work demonstrates that we can place the most advanced fault-tolerant error-correction technology on top of our hardware, increasing the projected logical performance of each device by an order of magnitude,” said Diraq’s CEO and Founder, Andrew Dzurak. “It means that every improvement in fault tolerance from here has the potential to offer an improvement in what our devices can do.”&lt;/p&gt;
&lt;p&gt;For Iceberg, this work marks an important step towards deploying Pinnacle on real hardware.&lt;/p&gt;
&lt;p&gt;“We have successfully demonstrated that Pinnacle’s logical performance advantage is achievable on Diraq’s hardware, and have carried the hardware mapping through to end-to-end compilation using NVIDIA CUDA-Q. CUDA-Q’s new logical layer gives us a flexible framework for expressing Pinnacle across distinct and evolving hardware platforms, without tightly coupling it to any one,” said Felix Thomsen, CEO and co-founder of Iceberg Quantum.&lt;/p&gt;
&lt;p&gt;The work is an early demonstration of NVIDIA CUDA-Q Logical in use.&lt;/p&gt;
&lt;p&gt;“Fault-tolerant quantum computing will advance faster when researchers can test new codes and architectures against real hardware constraints before the hardware is built,” said Sam Stanwyck, Director of Quantum Product at NVIDIA. “Using CUDA-Q Logical, Iceberg Quantum and Diraq showed that Pinnacle’s logical advantage carries through to a practical spin-qubit implementation, exactly the kind of rapid co-design needed to turn better ideas into useful quantum systems.”&lt;/p&gt;
&lt;p&gt;Together, Iceberg and Diraq are leveraging NVIDIA’s quantum platform to forge a powerful cross-stack collaboration.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Lifted Surgery</title>
          <pubDate>Fri, 11 Sep 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/lifted-surgery/</link>
          <guid>https://www.iceberg-quantum.com/blog/lifted-surgery/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/lifted-surgery/">&lt;p&gt;Last year we introduced &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.iceberg-quantum.com/blog/fast-surgery&quot;&gt;&lt;em&gt;fast surgery&lt;/em&gt;&lt;/a&gt;, a general technique for speeding up logical gates in QLDPC codes. We have now developed &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/abs/2609.11723&quot;&gt;&lt;em&gt;lifted surgery&lt;/em&gt;&lt;/a&gt;, a concrete realisation of fast surgery for general group algebra codes.&lt;/p&gt;
&lt;p&gt;Group algebra codes are a diverse family of codes that are capable of achieving very good finite-length performance. As a result, they form the bedrock of almost all existing QLDPC-based fault-tolerant architectures. The generalised bicycle codes used in the first version of the &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.iceberg-quantum.com/blog/pinnacle-and-series-seed&quot;&gt;Pinnacle architecture&lt;/a&gt;, the bivariate bicycle codes used in &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.ibm.com/quantum/blog/large-scale-ftqc&quot;&gt;IBM’s bicycle architecture&lt;/a&gt;, the codes used in &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.ionq.com/resources/fault-tolerant-quantum-computing-with-trapped-ions-the-walking-cat-architecture&quot;&gt;IonQ’s walking cat architecture&lt;/a&gt;, and the lifted product codes used in &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.oratomic.com/news/fault-tolerant-within-reach&quot;&gt;Oratomic’s resource estimate&lt;/a&gt; are all examples of group algebra codes.&lt;/p&gt;
&lt;p&gt;Group algebra codes also possess large amounts of symmetry, which makes it much easier to design circuit schedules for them across a range of different hardware platforms. When designing lifted surgery, one of our motivations was to preserve this symmetry, and we will release some further results soon on how this helps us design good hardware layouts for fast surgery.&lt;/p&gt;
&lt;p&gt;To preserve the symmetry of the codes, we made two concrete choices when designing lifted surgery. First, we use an identical copy of the base code as the surgery auxiliary system. This also ensures that the auxiliary system has the error-correction properties required to operate as a &lt;em&gt;fast&lt;/em&gt; auxiliary system. Second, we only connect the auxiliary system to the base code in specific ways, such that the resulting merged system is also given by a group algebra code.&lt;/p&gt;
&lt;p&gt;Fixing these two choices allowed us to give a rigorous mathematical treatment of lifted surgery. We showed that group algebra codes naturally decompose into blocks of logical qubits. Lifted surgery is able to act block-by-block to perform logical measurements. We identify three types of blocks, distinguished by how much addressability they allow:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Coarse blocks&lt;/strong&gt; where we can either measure all the logical qubits in the block, or none.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Fine blocks&lt;/strong&gt; where we can measure certain subsets of logical operators.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Completely fine blocks&lt;/strong&gt; where we can measure any subspace of logical operators of the same type in parallel.&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;lifted-surgery-fig1&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;lifted-surgery_fig01_block-by-block@3x.webp&quot; alt=&quot;A group algebra code split into fine and coarse blocks, with an auxiliary copy connected block by block by magenta links.&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;&lt;script defer src=&quot;lifted-surgery_fig01_block-by-block.js&quot;&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;p&gt;This last block is extremely powerful. For these blocks we can not only perform logical measurements with only one round of syndrome extraction, we can perform a large set of logical measurements at once, all with just one round of syndrome extraction. This combines the advantages of fast surgery with those of parallel/high-rate surgery.&lt;/p&gt;
&lt;p&gt;We also define several sub-families of Lifted Surgery, which allow us to achieve nice properties for specific sub-families of group algebra codes:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Scalar surgery&lt;/strong&gt; allows us to obtain a merged system large amounts of structure, making it ideal for implementing on physical hardware.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Lifted product surgery&lt;/strong&gt; utilises the underlying product structure of certain group algebra codes, allowing us to design surgery operations with lower connectivity requirements.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We were able to find several examples of codes with highly addressable logical via lifted surgery. For example, we find a code that requires a total of 198 data qubits (396 physical circuit qubits) to encode 8 logical qubits at a distance of 16, which consists of one completely fine block. This means we can measure any combination of the 8 logical operators of the code quickly and in parallel. These represent a 10× improvement in the space overhead compared to surface codes, while maintaining all the speed of fast surface code operations implemented via transversal gates. Compared to standard, sequential QLDPC surgery these examples represents a potential 50× speedup.&lt;/p&gt;
&lt;p&gt;It’s not enough to just perform logical measurements on isolated codes. We also need to be able to perform joint measurements across several codes. To address this we also designed a method for bridging lifted surgery systems. When we have two copies of the same code we can connect them with an auxiliary system, which consists of a single copy of the base codes. As above, the amount of addressability depends on the code used and the block decomposition. For example, for the distance 16 code we can bridge any logical qubit in the first code with any logical qubit in the second code. In fact, we can pairwise bridge any set of &lt;span class=&quot;math&quot;&gt;&lt;em&gt;r&lt;/em&gt;&lt;/span&gt; logical qubits in the first code with any set of &lt;span class=&quot;math&quot;&gt;&lt;em&gt;r&lt;/em&gt;&lt;/span&gt; logical qubits in the second code.&lt;/p&gt;
&lt;p&gt;To assess the performance of lifted surgery we ran simulations of several different experiments, including scalar surgery, sequences of surgery operations on completely fine blocks and bridged lifted surgery between codes. While the physical circuits are all LDPC, the meta-checks that make lifted surgery fast can often be quite, resulting in dense decoding matrices. We developed a a new &lt;em&gt;two-pass sparsifying decoder&lt;/em&gt; to address this. The decoder uses two optimisations to reduce the complexity of the decoding problem. First, it splits the decoding matrix into two seperate matrices, one for X detectors and one for Z detectors. It first decodes the X detector matrix, and then uses that information to update the priors for the Z decoding matrix. This is a similar technique used for correlated matching in the surface code. The second optimisation is to sparsify the decoding matrices using an information set algorithm. We search for low weight vectors in the row spaces of each decoding matrix and use these to construct new sparse matrices with the same row spaces as the original decoding matrices. We decode on these sparse matrices, and convert the corrections back to the original decoding matrices to make logical predictions.&lt;/p&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;&quot; data-src=&quot;lifted-surgery_fig02_simulations.json&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;lifted-surgery_fig02_simulations@3x.webp&quot; alt=&quot;Left: logical error rate against physical error rate for GB and BB codes with power-law fits. Right: failure rate per logical operation for standard and lifted surgery variants.&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;
&lt;/div&gt;
&lt;p&gt;Our simulations show that lifted surgery is capable of reaching utility-scale performance. With a code consisting of just 90 data qubits (180 physical circuit qubits) at physical error rates of 0.1% we can already reach the 0.0001% failure rate per logical operation needed for early fault-tolerant simulations in materials science. For the distance 16 code we took millions of shots of a lifted surgery operation and found no logical failures. We also ran simulations of bridged lifted surgery and found that performance was identical to lifted surgery on single codes.&lt;/p&gt;
&lt;p&gt;We have already begun integrating lifted surgery into the next version of Pinnacle. This involves optimising the code choices and surgery operations for the target logical failure rates; optimising the syndrome extraction circuits across the different hardware platforms; and optimising algorithmic compilation to fully utilise the parallelism made available by lifted surgery. We expect lifted surgery to become a core part of Pinnacle going forward, substantially reducing logical runtimes across a wide range of applications.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Pinnacle and Series Seed</title>
          <pubDate>Fri, 13 Feb 2026 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/pinnacle-and-series-seed/</link>
          <guid>https://www.iceberg-quantum.com/blog/pinnacle-and-series-seed/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/pinnacle-and-series-seed/">&lt;p&gt;It’s an exciting time in quantum computing. It can be difficult to see through the noise amid all the headlines and bold claims, but progress is real and accelerating. For the first time, multiple hardware modalities have credible paths forward, with a realistic shot at reaching tens to hundreds of thousands of physical qubits within the next few years.&lt;/p&gt;
&lt;p&gt;Our aim with Iceberg Quantum is to be the architecture company: to help accelerate the transition to, and ultimately power, the fault-tolerant era of quantum computing by defining how this hardware computes.&lt;/p&gt;
&lt;p&gt;Our approach is to build the world’s best fault-tolerance research lab, and to partner closely with leading hardware companies to work toward implementation.&lt;/p&gt;
&lt;p&gt;Recognising that we’re still early in our journey, today we’re excited to announce a few milestones on our progress.&lt;/p&gt;
&lt;p&gt;We’ve released &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/abs/2602.11457&quot;&gt;Pinnacle&lt;/a&gt;, our first full fault-tolerant quantum computing architecture. It validates our core thesis: that architectures can be an order of magnitude better, requiring 10x fewer physical qubits. To demonstrate this, we compile a canonical benchmark application—factoring 2048-bit RSA integers—long thought to require millions of physical qubits, and show it could instead be achieved with fewer than one hundred thousand. We believe this represents a meaningful step toward utility-scale quantum computing, and warrants a reassessment of assumptions around when cryptographically relevant machines may be built.&lt;/p&gt;
&lt;p&gt;We’ve formed an exceptional initial team and are excited to expand it further, with several people joining shortly as we grow beyond Sydney, opening our first overseas office in Berlin and expanding our team in the US. We’re bringing together some of the best people in the world working on fault tolerance, who have authored many of the most significant advances in the field in recent years.&lt;/p&gt;
&lt;p&gt;Finally, we’ve raised $6 million in Seed funding from LocalGlobe, Blackbird, and DCVC. The new funding will help us scale our work across research and design partnerships with leading hardware companies.&lt;/p&gt;
&lt;p&gt;We’re incredibly excited about the future of quantum computing, as fault tolerance, which once felt so distant, is coming into focus. If you are too, perhaps you should consider joining us.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Modular and Efficient Surgery</title>
          <pubDate>Fri, 21 Nov 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/modular-and-efficient-surgery/</link>
          <guid>https://www.iceberg-quantum.com/blog/modular-and-efficient-surgery/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/modular-and-efficient-surgery/">&lt;p&gt;Code surgery is a method for fault-tolerantly measuring logical operators of any QLDPC code. When supplemented with prepared magic states, this is sufficient for universal, fault-tolerant quantum computation using Pauli-based computation. It is made possible by measurement gadgets – auxiliary systems that are combined with the code block to reduce high-weight logical operator measurements to a product of low-weight measurements.&lt;/p&gt;
&lt;p&gt;The practicality of the method depends on the feasibility of implementing the gadget in hardware. Specifically, the inclusion of the gadget should not significantly increase the complexity of implementation over that of the code block itself. This ensures that any hardware platform capable of implementing the code will naturally also support the gadgets. Simultaneously, they should also maintain the low overhead that justifies the use of high-rate QLDPC codes over alternatives such as the surface code.&lt;/p&gt;
&lt;p&gt;This motivates two criteria that should be met for gadgets to be suitable for use in real quantum computing architectures — &lt;strong&gt;modularity&lt;/strong&gt; and &lt;strong&gt;efficiency&lt;/strong&gt;. In our new &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/abs/2511.15989&quot;&gt;preprint&lt;/a&gt;, we present the first gadgets that simultaneously satisfy both of these criteria.&lt;/p&gt;
&lt;h4 id=&quot;modularity&quot;&gt;Modularity&lt;/h4&gt;
&lt;p&gt;By &lt;strong&gt;modularity&lt;/strong&gt;, we mean that the gadgets should only need to be engineered once and then be  reusable indefinitely through any computation. Many past designs fail this test, since they require bespoke gadgets to measure each of the exponentially large number of logical operators. This would necessitate wholesale reconfiguration of qubits for each logical measurement. This is particularly problematic since the adaptive nature of Pauli-based computation means that the logical measurement sequence for an algorithm cannot be predetermined. Instead, an entirely different quantum circuit would need to be calculated and implemented in real-time for each logical measurement cycle. We are not convinced this level of control is achievable in practice.&lt;/p&gt;
&lt;p&gt;We achieve modularity by instead designing a system consisting of a small number of essentially fixed gadgets. By docking these gadgets onto different sites of the code block, we can measure any logical operator. For example, we show how cyclic shifts of just four gadgets suffice to measure any logical operator on a family of generalised bicycle (GB) codes. The control problem is thereby reduced to a simple input of how many sites each gadget should be shifted before docking.&lt;/p&gt;
&lt;p&gt;The following animation shows an example of measuring a random sequence of logical operators on a GB code using our gadget system. Open circles represent data qubits and teal and violet squares represent Z and X check qubits; the lines connecting these to gadgets show where each gadget is connected. The arcs connecting the gadgets represent bridges. Notice how all that changes for each logical operator is that the connection sites for each gadget are shifted. Replacing dynamic rewiring within gadgets with this “plug and play” operation makes QLDPC code surgery a much more realistic prospect!&lt;/p&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;modular-gadgets-fig1&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;modular-and-efficient-surgery_fig01_gadgets@3x.webp&quot; alt=&quot;Four gadgets docked onto a row of data and check qubits of a generalised bicycle code, joined by bridges.&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;&lt;script defer src=&quot;modular-and-efficient-surgery_fig01_gadgets.js&quot;&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;h4 id=&quot;efficiency&quot;&gt;Efficiency&lt;/h4&gt;
&lt;p&gt;By &lt;strong&gt;efficiency&lt;/strong&gt;, we mean that the gadgets achieve order-of-magnitude spacetime reductions over surface code lattice surgery. This criterion is crucial, since overhead reductions are the reason to prefer QLDPC codes over surface codes. Designing gadgets with low space overhead was achieved by &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2410.02213&quot;&gt;previous work&lt;/a&gt;. However, recent work has raised questions about the time overhead. In particular, IBM Quantum’s recent preprint &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2506.03094&quot;&gt;&lt;em&gt;Tour de gross&lt;/em&gt;&lt;/a&gt; applied the &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2503.10390&quot;&gt;extractor&lt;/a&gt; formalism to design the first modular gadget system for a practical QLDPC code. However, the gadget system they present cannot measure an arbitrary logical operator in a single logical measurement cycle (only a generating set). Overcoming this limitation requires compilation that increases the time overhead for universal fault-tolerant quantum computation by an order of magnitude. As a result, there is no substantial spacetime saving over the surface code, only a tradeoff of time and space.&lt;/p&gt;
&lt;p&gt;By contrast, our gadgets are efficient as they maintain a low space overhead without any corresponding increase in the time overhead. This is because they allow measurement of &lt;em&gt;any&lt;/em&gt; logical operator in a single logical cycle (i.e., &lt;span class=&quot;math&quot;&gt;&lt;em&gt;d&lt;/em&gt;&lt;/span&gt; rounds of syndrome extraction), removing the need for additional compilation. QLDPC codes have long been asserted to give order-of-magnitude overhead reductions. Our gadgets make this promise real by manifesting such spacetime reductions in a concrete, modular design.&lt;/p&gt;
&lt;h4 id=&quot;more-to-come&quot;&gt;More to Come&lt;/h4&gt;
&lt;p&gt;Our modular, efficient gadgets demonstrate a realistic construction to achieve the promise of low-overhead quantum computing with QLDPC codes. However, they are not the end of the story. In the future, we look forward to synthesising this work with last month’s development of &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/pdf/2510.04521&quot;&gt;fast surgery&lt;/a&gt; to design modular gadgets that achieve order of magnitude reductions in both space &lt;em&gt;and&lt;/em&gt; time overhead compared with surface codes. We are also excited to apply our construction to a wider range of QLDPC codes tailored to meet the needs of different hardware platforms, and to integrate it into a fully fledged fault-tolerant architecture. While surface code architectures have been heavily optimised already, the QLDPC code architectures of today are at the very start of what’s possible, and much remains to be explored, tried and built. By combining new discoveries with practical design for real hardware, we look forward to accelerating the onset of useful quantum computers further.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Fast Surgery</title>
          <pubDate>Mon, 13 Oct 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/fast-surgery/</link>
          <guid>https://www.iceberg-quantum.com/blog/fast-surgery/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/fast-surgery/">&lt;p&gt;Quantum computers offer exponential speedups for certain problems, promising to unlock new frontiers of computation that will remain forever out of reach to classical computers. But actually running a quantum computer is slow. The time it takes to perform one logic gate, its &lt;em&gt;logical clock speed&lt;/em&gt;, is orders of magnitude slower than on a classical computer.&lt;/p&gt;
&lt;p&gt;On top of this, discussions of quantum speedups often overlook that most high-value algorithms require extremely long circuits. Executing these within a realistic runtime is challenging (and for some hardware platforms effectively impossible) with current methods. Improvements in logical clock speed are therefore essential to make such algorithms practically and economically viable.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Why is the logical clock speed so slow?&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Partly because the underlying physical operations are simply slower. A modern classical chip can perform a logic gate in about one picosecond, while some quantum hardware platforms take tens or even hundreds of microseconds for each elementary physical operation.&lt;/p&gt;
&lt;p&gt;But raw physical speed isn’t the full story. Useful quantum computation relies on logical qubits — collections of many physical qubits encoded within quantum error correcting codes to protect against the inherently higher noise of quantum devices. The logical clock speed is ultimately set by how fast we can perform logical operations on these encoded qubits, and the procedures required to do so &lt;em&gt;fault-tolerantly&lt;/em&gt; often introduce additional large time overheads.&lt;/p&gt;
&lt;p&gt;In our recent &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://arxiv.org/abs/2510.04521&quot;&gt;preprint&lt;/a&gt;, we introduce &lt;strong&gt;Fast Surgery&lt;/strong&gt;, a new method that removes one of the major time overheads in fault-tolerant quantum computing and makes possible a 15–30× speedup for useful quantum algorithms. It is a concrete step toward realising both hardware- and time-efficient, utility-scale quantum computing, and a significant advance for the broader QLDPC code paradigm.&lt;/p&gt;
&lt;p&gt;In this post, we give a short summary of what we did and how it works.&lt;/p&gt;
&lt;h4 id=&quot;compressing-logic&quot;&gt;Compressing logic&lt;/h4&gt;
&lt;p&gt;One of the most popular methods for performing fault-tolerant logic is by making measurements of logical qubits. The main technique for performing these measurements is known as surgery, and was first developed for surface codes before being generalised to quantum LDPC codes. Surgery works by carefully attaching and detaching a set of auxiliary qubits to the error-correcting code. After detaching these qubits, we physically measure them to infer the outcome of the logical measurement. But when noise is present, each of these physical measurements incurs some probability of being flipped. If any physical measurement is flipped, then our logical measurement is also flipped, rendering it useless. To alleviate this, traditional surgery schemes perform multiple rounds of the surgery operation. The number of rounds needed is more than an order of magnitude for large fault-tolerant algorithms (typically 15–30 in practice). This introduces enough redundancy to the scheme to correct measurement errors, at the cost of a significant increase in time spent.&lt;/p&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;fast-surgery-fig1&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;fast-surgery_fig01_redundancy@3x.webp&quot; alt=&quot;Four code sheets measured round after round along a time arrow, versus one sheet carrying several equivalent logical operators with a single auxiliary system.&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;&lt;script defer src=&quot;fast-surgery_fig01_redundancy.js&quot;&gt;&lt;/script&gt;
&lt;/div&gt;
&lt;p&gt;Fast Surgery is designed to reduce the amount of time needed to perform logic by extracting reliable logical measurements in just a single round. The key insight behind Fast Surgery is that the redundancy needed for fault tolerance doesn’t have to come from repeating operations in time, it can instead be drawn directly from the structure of the code itself. In an error-correcting code, logical information is stored in a distributed way across many physical qubits, meaning there are multiple, equivalent representations of any logical operator. Fast Surgery exploits this fact; rather than performing the same measurement several times to gain redundancy, we can measure several representations at once. This transforms time redundancy into spatial redundancy, compressing many sequential rounds into one parallel operation.&lt;/p&gt;
&lt;p&gt;To achieve this, we construct an auxiliary system of qubits that couples simultaneously to all these equivalent representations. This auxiliary system need to be carefully constructed to ensure that the error correcting capabilities of the code are not affected during the procedure. We find a sufficient set of conditions (and an associated constructive scheme) to ensure that the distance of the error correcting code is preserved. When we detach and measure these auxiliary qubits, we obtain a set of correlated outcomes that collectively provide the same level of fault tolerance that previously required many rounds of repetition. The result is a fully fault-tolerant measurement that completes in a single logical cycle.&lt;/p&gt;
&lt;p&gt;To evaluate the performance of fast surgery we ran numerical simulations comparing it to the most widely used standard surgery scheme for quantum LDPC codes. We simulated a small distance 3 multi-cycle code, suitable for early fault-tolerance demonstrations. The aim was to test whether a single-round implementation could still achieve fault-tolerant behaviour.&lt;/p&gt;
&lt;div class=&quot;iq-embed&quot;&gt;
&lt;div data-iq-figure=&quot;&quot; data-src=&quot;fast-surgery_fig02_logical-error-rate.json&quot;&gt;&lt;/div&gt;&lt;noscript&gt;&lt;img src=&quot;fast-surgery_fig02_logical-error-rate@3x.webp&quot; alt=&quot;Log–log plot: fast surgery in one round has the lowest logical error rate at every physical error rate; single-round standard surgery stays above the pseudo-threshold.&quot; loading=&quot;lazy&quot;&gt;&lt;/noscript&gt;
&lt;/div&gt;
&lt;p&gt;Let’s unpack these results a bit. On the x-axis, we plot the &lt;em&gt;physical error rate,&lt;/em&gt; how often the hardware itself makes mistakes during basic operations like measurements. On the y-axis, we plot the &lt;em&gt;logical error rate,&lt;/em&gt; how often the encoded information fails despite the protection of the error-correcting code. The dashed, black line represents the pseudo-threshold, the point where the logical error rate matches the physical one. Any points above this line are performing worse than if we hadn’t used error correction at all. Points below the line represent the region where error correcting is improving the reliability of our computation. For practical schemes we want to be firmly below this line.&lt;/p&gt;
&lt;p&gt;When we attempt to perform a logical measurement using just a single round of standard surgery the logical error rate remains too high to cross the pseudo-threshold line. Standard surgery only starts to work when we repeat the measurement several times. Fast Surgery, on the other hand, achieves fault-tolerant performance in a single round. In our simulations it performs better than standard surgery, even when the latter is repeated several times. Because Fast Surgery requires fewer rounds of measurement, it reduces the overall execution time and limits the accumulation of other errors. This time compression directly improves logical performance, showing that redundancy drawn from the code structure can effectively replace redundancy in time.&lt;/p&gt;
&lt;h4 id=&quot;another-step-forward-for-qldpc-codes&quot;&gt;Another step forward for QLDPC codes&lt;/h4&gt;
&lt;p&gt;This work builds on earlier advances in making QLDPC codes practical for quantum computation. A few years ago, we introduced the first generalised surgery framework for QLDPC codes, which brought the leading way of doing logic in surface codes to the QLDPC setting. Fast Surgery goes a step further: it shows that QLDPC codes can now perform these operations both faster and more efficiently than existing surface code schemes. We’re excited about what this unlocks and look forward to sharing further advances soon.&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Partnering with Diraq</title>
          <pubDate>Fri, 01 Aug 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/partnering-with-diraq/</link>
          <guid>https://www.iceberg-quantum.com/blog/partnering-with-diraq/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/partnering-with-diraq/">&lt;p&gt;We’re excited to announce we’ve started working with Diraq, which is building silicon spin qubit hardware. We’re applying our QLDPC-based approach to fault tolerance to help accelerate their roadmap to utility.&lt;/p&gt;
&lt;p&gt;&lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.diraq.com/newsdesk/iceberg-quantum-boosts-diraqs-error-correction-expertise&quot;&gt;→ Read their full announcement on Diraq’s website&lt;/a&gt;&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Partnering with Oxford Ionics</title>
          <pubDate>Thu, 17 Jul 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/oxford-ionics-partnership/</link>
          <guid>https://www.iceberg-quantum.com/blog/oxford-ionics-partnership/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/oxford-ionics-partnership/">&lt;p&gt;We’re excited to be partnering with Oxford Ionics, a trapped-ion quantum computing company. Together, we’re developing the architecture for their QLDPC-based utility-scale system, a bold plan that plays to the strengths of their hardware and a major validation of our approach.&lt;/p&gt;
&lt;p&gt;We’re helping shape the architecture of the first truly useful quantum computers. The transition from science experiments to useful technology is underway, and we’re proud to be accelerating it.&lt;/p&gt;
&lt;p&gt;→ &lt;a rel=&quot;noopener external&quot; target=&quot;_blank&quot; href=&quot;https://www.oxionics.com/announcements/oxford-ionics-and-iceberg-quantum-partner&quot;&gt;Read their full announcement on Oxford Ionics’ website&lt;/a&gt;&lt;/p&gt;
</description>
      </item>
      <item>
          <title>Introducing Iceberg Quantum</title>
          <pubDate>Tue, 25 Mar 2025 00:00:00 +0000</pubDate>
          <author>Unknown</author>
          <link>https://www.iceberg-quantum.com/blog/introducing-iceberg-quantum/</link>
          <guid>https://www.iceberg-quantum.com/blog/introducing-iceberg-quantum/</guid>
          <description xml:base="https://www.iceberg-quantum.com/blog/introducing-iceberg-quantum/">&lt;p&gt;Iceberg Quantum is a quantum architecture company. Our goal is to make useful quantum computing happen much sooner and with far less hardware by designing fault-tolerant architectures based on QLDPC codes.&lt;/p&gt;
&lt;p&gt;Today, we’re excited to announce our launch, a &lt;strong&gt;$2 million pre-seed round&lt;/strong&gt; led by &lt;strong&gt;Blackbird&lt;/strong&gt; with participation from &lt;strong&gt;LocalGlobe&lt;/strong&gt;, and our first major partnership with &lt;strong&gt;PsiQuantum&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Background&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;We believe large-scale, fault-tolerant quantum computing will be transformative, yet realising this potential remains incredibly difficult due to one critical roadblock: the massive hardware overhead required for quantum error correction.&lt;/p&gt;
&lt;p&gt;Qubits are inherently far more error-prone than transistors. To perform any useful computation, quantum computers require an architecture that protects programs against these errors using a fault-tolerant encoding, where instructions are carried out on &lt;em&gt;logical&lt;/em&gt; qubits rather than physical ones. These logical qubits are created by combining several error-prone physical qubits into error correcting codes.&lt;/p&gt;
&lt;p&gt;Today, the predominant approach to designing fault-tolerant architectures is based on the surface code, which is highly qubit-intensive, requiring at least 1,000 physical qubits to encode a single logical qubit. This overhead is the key reason why the applications we’re all excited about remain frustratingly distant.&lt;/p&gt;
&lt;p&gt;But in the last few years, an alternative path has opened up. Breakthroughs in quantum LDPC codes, combined with enabling advances in hardware, point to a dramatically more efficient route to fault tolerance.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Iceberg Quantum&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;We, three recent PhD graduates in fault tolerance, founded Iceberg Quantum based on the conviction that QLDPC-based architectures are the future of fault-tolerant quantum computing. We believe these architectures will be the critical enabling technology that makes quantum computing practical, unlocking useful applications much sooner and with more than an order of magnitude less overhead. In the long run, they will be essential to making quantum compute abundant.&lt;/p&gt;
&lt;p&gt;We also believe that realising this vision requires a focused, dedicated effort. The need for quantum error correction means that, unlike in classical computing, the first truly useful quantum computers will require complex, sophisticated architectures from the outset. Designing these architectures is a big and still underestimated challenge. The fastest way forward is to tackle this challenge head-on, within a dedicated company, solely focused on developing the best possible fault-tolerant architectures.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Looking forward&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;To take the first step, we’ve raised a $2 million pre-seed round led by Blackbird, with participation from LocalGlobe. We’re deeply grateful for their support and will use this capital to build a team of the world’s best quantum architects dedicated to designing the best fault-tolerant architectures and nothing else.&lt;/p&gt;
&lt;p&gt;We’re also thrilled to announce our first partnership with PsiQuantum. The PsiQuantum team has made a bold bet on photonics—one we deeply respect—while taking a fault-tolerance-first approach from day one, a principle we share. Together, we’ll work towards a more efficient path to useful quantum computing by applying QLDPC-based architectures to their photonic platform.&lt;/p&gt;
&lt;p&gt;The opportunity to shape the future of quantum computing is enormous, but so is the work ahead. If you share our ambition and want to help bring fault-tolerant quantum computing closer to reality—whether by joining our team or partnering with us—we’d love to hear from you.&lt;/p&gt;
</description>
      </item>
    </channel>
</rss>
