WarpSpeed Brings Expert-Level AI to Hardware Design

WarpSpeed is doubleAI’s AI system for expert-level tasks. We applied WarpSpeed to hardware design and optimization. Read on for all the results, which include:

• State-of-the-art results on NVIDIA’s CVDP benchmark. We demonstrate the impact of WarpSpeed’s formal verification and self-improvement capabilities, achieving an 82.5% hardware-optimization score and solving 98.5% of the evaluated hardware-design problems.
• Formally verified implementations with zero hacks. We show how WarpSpeed’s verification system avoids incorrect solutions. WarpSpeed produced 0% hacks, while a leading system produced hacks in 16.2% of evaluated cases.
• Autonomous hardware design. We used WarpSpeed to autonomously design and optimize hardware across a diverse set of tasks, including a cryptographic accelerator and a lane-detection pipeline translated from software into hardware.

Hardware Design Is Ready for AI Agents With Strong Verification

Semiconductors are everywhere.  Every phone or computer we produce, every vehicle we drive (autonomous or otherwise), and every AI model we train rests on the same foundation: a chip packing billions of transistors and logic gates into one meticulously engineered piece of silicon.

Trillions of dollars have been invested in refining how chips are designed and manufactured, with individual projects costing hundreds of millions of dollars. Yet the industry remains one of the fundamental bottlenecks of the global economy. Designing a chip can take years and require coordination across hundreds of specialists spanning dozens of different disciplines.

Artificial Superintelligence systems built for exploration, learning, and verification could change that equation, testing more alternatives, learning from each iteration, and rigorously validating increasingly ambitious designs. At scale, this could shorten design cycles, reduce engineering costs, and make specialized hardware viable for many more workloads.

‍

WarpSpeed is doubleAI’s self-improving, strongly verified AI system for expert-level tasks. It has demonstrated state-of-the-art performance across diverse domains, including kernel optimization, performance engineering, and quantum circuit complexity.

We have now applied WarpSpeed to a new domain: hardware. We evaluate it on NVIDIA’s Comprehensive Verilog Design Problems (CVDP), a benchmark suite covering RTL generation, completion, modification, debugging, and optimization, and demonstrate its capabilities on several autonomous hardware-design tasks.

The key question is not only how well WarpSpeed performs, but whether its solutions are actually correct. We show how its verification system rejects optimizations that pass benchmark tests but violate the intended behavior. In our evaluation, Claude Code produced invalid solutions in 16.2% of cases, while WarpSpeed produced 0%. Later in the blog, in the Technical Deep Dive, we examine the hacks we found, how WarpSpeed verifies its solutions, and how self-improvement contributes to its results.

WarpSpeed Beats Qwen3.8-Max Agentic System on Autonomous Design of Cryptographic Chip

Before diving into the benchmarks and into WarpSpeed, let’s start with something more tangible: two compact demonstrations of what an autonomous hardware-design agent can already build. In one, WarpSpeed optimized a cryptographic chip head-to-head on the same design showcased by Qwen3.8-Max. In the other, it took a classic lane-tracking algorithm and turned it into dedicated hardware.

We begin with an example that comes straight from Qwen3.8-Max's own release blog, where they present an agent optimizing a GCD / RSA cryptographic accelerator — a chip built to do the heavy math behind encryption far faster than a general-purpose processor could. (Full details of the chip are on their blog.)

In their setup, their agent, based on the flagship Qwen3.8-Max model, started from a simple, functionally correct implementation. It then iteratively optimized it through simulation, synthesis, and physical design. We took that exact same initial design, and gave it to WarpSpeed as its  starting point. We then gave WarpSpeed the same optimization task and budget that Qwen used, and sent it along to optimize. The interactive 3D view below showcases the results.
‍

We compared the two optimized designs, ours and Qwen’s, in terms of area, clock speed and power. Qwen’s solution serves as a strong baseline, having outperformed other SoTA agents in its reported results. WarpSpeed achieves a 92% reduction in die area from the naive initial design, compared with 81% for Qwen3.8-Max, while also reaching a 2.6× higher maximum clock speed (≈1.30 GHz vs. 500 MHz) with similar power consumption.

Lane-Detection Hardware

Another use case we used WarpSpeed for is a lane-detection algorithm: a classic computer-vision pipeline that identifies road lanes and translates them into a dedicated hardware design, similar to perception workloads implemented directly in automotive chips.

In modern cars, tasks like lane detection often run on specialized hardware built for real-time vision, where every frame must be processed quickly and efficiently. Production automotive chips handle far more: pedestrian and sign detection, sensor fusion, emergency braking, and more. However, lane detection provides a clean, self-contained example of the same design paradigm.

We handed WarpSpeed the reference implementation - the original Python code, along with a set of example driving frames and their expected lane outputs - and asked it to produce synthesizable hardware that implements the algorithm and matches the reference within a given tolerance.

WarpSpeed turned that task into a chip capable of processing full 1280×720 (720p) frames at about 108 fps, roughly 9 ms per frame, while using under 1 MB of on-chip memory and targeting a 130 nm standard-cell library [1]. Importantly, this is not a full production automotive stack, but a compact demonstration of the potential of using AI system for building hardware.

NVIDIA's CVDP Benchmark

NVIDIA’s Comprehensive Verilog Design Problems (CVDP) benchmark evaluates AI systems on core hardware-design tasks, including translating specifications into RTL, modifying and debugging existing designs, and optimizing implementations while preserving correctness.

These tasks sit in the digital-design stage of chip development, before fabrication, and provide a direct way to evaluate WarpSpeed’s ability to explore while rigorously verifying correctness.

We focus on two main categories in the benchmark: (1) hardware optimization, our primary focus, and (2) hardware design, including specification-to-RTL generation, code completion, modification, and debugging.

The first task is hardware optimization. Here, the agent is given existing hardware code and a natural-language specification and must produce a functionally identical design using fewer cells. Cell count is a key driver of area and complexity, making optimization an important part of hardware design.

Of course, a strong benchmark score is only meaningful if the optimized design is actually correct…

As it happens, the automated tests in CVDP can be exploited by RTL designs that pass the evaluation while failing to preserve the intended behavior. We therefore independently verify each solution against the benchmark tests, the specification, and the original implementation to identify hacks. The results are presented in the figure below.

Verification allows WarpSpeed to test designs while ensuring they preserve the required behavior, and self-improvement lets it learn from previous attempts and carry those lessons forward. Together, these components drive the full system to 82.5% reduction of cell count, compared with 76.6% without self-improvement, while both variants produce 0% hacks in our evaluation. By comparison, Claude Code with Fable reaches 80.1% raw performance, but 16.2% of its solutions are invalid. after removing them, its verified score drops to 67.9%. In the technical deep dive, we give concrete examples of these invalid optimizations and explain how WarpSpeed’s verification mitigates them.

Beyond optimization, we also evaluated WarpSpeed across CVDP’s core hardware-design tasks, used by the other baselines: generating RTL from a specification, completing partial code, modifying existing designs, and debugging. Once again we compared it head-to-head against leading systems including AGENTRYS, NVIDIA’s ACE-RTL, and Claude Code with Fable.
‍

‍

Technical Deep Dive

So far, we presented only our results. By now it’s time that we also get into the details, including what we learned about hacks, verification, and self-improvement on CVDP.

Hacks

We evaluated the agents’ solutions on CVDP for correctness. We found several commonly recurring classes of hacks in their designs:

• State bypass — the design removes required internal state and reads directly from live inputs instead.
• Computation bypass — the design avoids part or all of the required computation, for example by directly forwarding outputs or generating control signals independently of the intended operation.
• Test-set overfitting — the design implements a cheaper but behaviorally different architecture that matches the original on tested scenarios while failing on valid cases outside the benchmark coverage.

Below, we walk through one example of each pattern using actual hacked designs submitted by Claude Code with Fable. Crucially, all of these hacked solutions pass 100% of the benchmark’s tests, despite failing to implement the intended specification or preserve equivalence with the original RTL.

One subtle but important point is that some hacks exploit implementation choices in the original RTL. In isolation, an agent’s modification may even seem reasonable. But the task requires strict functional equivalence to the original design - so changing those semantics, even in seemingly sensible ways, can still produce fundamentally different behavior and is therefore incorrect.

Hacking Examples

This problem implements a miniature exchange core: it takes eight bids (buyer offers) and eight asks (seller prices), finds the highest bid and lowest ask, and triggers a trade when they cross.

The original design snapshots all prices into registers when the job begins and operates only on that frozen copy, so later input changes cannot affect the outcome. The agent's task is to shrink the chip while preserving this behavior. The solution Claude Code submitted contains a hack: to save the area those registers cost, it removed them and reads prices straight from the live input wires, so it decides from whatever is on the wires at that moment, not the values captured at the start.

The illustration shows the failure the hack can cause: both designs get a best bid of 100 against asks all at 200 - no cross, so no trade. Mid-scan, one ask flickers to 50 for a single cycle. The snapshot design never sees the blip and correctly makes no trade; the hacked live-read design treats the transient 50 as the best ask and fires a wrong trade at 100 the original RTL never would.

Why do the tests miss it?  The benchmark tests keeps inputs fixed for the entire job. Under those conditions, a captured snapshot and a live wire behave identically.
‍

This problem asks to implement a simple serial link — the kind of interface chips use to talk to each other over a single wire. Given a word of 8, 16, 32 or 64 bits, a transmitter sends it across to a receiver, which reassembles the word and raises done when the transfer completes.

Think of "done" as the chip announcing "message sent." The original raises done only when a valid transfer completes. The hacked Claude Code design, however, bypasses the serial machinery, copies a width-masked version of the input directly to the output, and generates done from a timer. As a result, it can announce "message sent" when no valid transfer has taken place - for example, during startup or in an unsupported run configuration.

In the illustration, both designs run the same timeline. The correct design raises done exactly once - at the single moment a real transfer completes. The hacked design keeps pulsing done on its timer, including the stretches where the link should stay silent — causing downstream logic to act on transfers that never happened.

Why do the tests miss it?  The benchmark tests wait for done and checks the final output under a small set of valid configurations, but it does not test the states where the link is required to remain silent. The hack exploits exactly that gap.
‍‍

This problem asks to implement a general-purpose counter chip with six personalities: count up, count down, count modulo-N, Gray code, and two classic shift-register patterns (Johnson and Ring). In the original design, all six counters run in parallel at all times, each keeping its own private state, and a selector simply displays whichever one you ask for - like six clocks on a wall, each ticking its own way, with a switch choosing which face to show.

In the illustration, both designs begin in UP mode and count 1, 2, 3… in lockstep — completely indistinguishable. At cycle 6, the selector switches to RING, a mode whose state must always contain exactly one active bit rotating through the register. Watch what happens in the bottom row at the moment of the switch.

Six separate state registers cost silicon, so Claude Code’s hacked solution collapsed them into a single shared register and reinterprets its value based on the selected mode. As long as the chip stays in one mode from reset, the behavior matches the original. But when the selector changes mid-run, the shared register carries the up-counter’s leftover state into ring mode — producing two active bits at once, a state a valid ring counter can never reach.

Why do the tests miss it? Every benchmark test resets the chip and runs a single mode from zero; none switches modes during execution.

Verification

Strong verification is one of WarpSpeed’s core capabilities. In this section, we outline the verification tools available in the benchmark and the way in which WarpSpeed leverages them. We then show how its approach rules out the hacks from the previous section and handles properties that are difficult to prove directly.

Verification Tools

Hardware engineering has developed some of the most rigorous verification practices in digital engineering, largely out of necessity. Unlike software, chips sometimes cannot be patched after fabrication, so a single design error can be extremely costly. The industry has built a broad set of verification techniques and tools to reduce that risk. CVDP gives participating agentic systems access to a small set of open-source tools from this broader hardware-verification ecosystem:

• Testbenches. The agents can write their own tests and simulate the chip logic, driving the chip cycle by cycle and checking its behavior against both the original design and the spec.
• Formal verification. Using the open-source Yosys + SymbiYosys toolchain with SMT solvers, the agent can check assertions across reachable input sequences and receives either a counterexample or a proof within the checked depth.
• Synthesis. Every candidate RTL design can be compiled to an actual gate-level netlist with the same open-source flow the benchmark grades with, so the agent optimizes against the resulting cell and wire counts.

WarpSpeed’s Verification Approach

WarpSpeed uses the available verification tools as part of its own reasoning loop. Before optimizing a design, its agents turn the specification and original RTL into a formal contract: a set of properties that any valid solution must satisfy. Other agents then challenge the contract adversarially, looking for missing behaviors or overly restrictive assumptions, and refine it until it captures the intended behavior closely enough to evaluate candidate designs.

During optimization, every RTL design candidate must satisfy this contract before it can be accepted. When a property is difficult for the verifier to prove directly, WarpSpeed can decompose it into several simpler properties that together establish the same requirement. This makes verification more tractable while still protecting against optimizations that pass the benchmark tests but change the intended behavior.

Avoiding the Hacks - How Verification Prevented WarpSpeed From Hacking

The clearest way to see the value of WarpSpeed’s verification approach is to revisit the three hacks from the previous section and examine how they are caught.

The hacked design in this problem removes the input snapshot and reads prices directly from the live wires. Because the benchmark tests keep those inputs fixed, the shortcut still passes every test. WarpSpeed’s contract explicitly requires the result to depend on the prices captured at the start of the operation:

// The output must equal the max bid captured at the START cycle
mb_s <= max_bid(bid_orders);        // snapshot the winner at start
...
assert(matched_price == mb_s);    // the snapshot check to prove

The verifier is free to change the live inputs after the start cycle. Any design that reads those inputs instead of preserving the original snapshot behavior will disagree with the captured value and fail the proof. WarpSpeed’s verification therefore prevents this hack by construction.
‍

In this problem, the hack bypassed the serial link entirely: it copied the input directly to the output and generated done from a predefined timer. This could produce false completion signals, telling the surrounding system that a transfer had finished even when no valid transfer occurred.

The contract catches this by turning the intended behavior into explicit obligations. The link must remain silent during reset and for unsupported widths, and whenever a valid transfer completes, the output must contain exactly the expected word:

// During reset, the link must stay silent.
if (!reset_n) begin
    assert(data_out == 0);
    assert(done == 0);
end

// Unsupported widths must also remain silent.
if (sel == 3'b000 || sel > 3'b100) begin
    assert(data_out == 0);
    assert(done == 0);
end

// When a valid transfer completes, the payload must be correct.
if (done) begin
    case (sel)
      3'b001: assert(data_out == {56'h0, data_in[7:0]});
      3'b010: assert(data_out == {48'h0, data_in[15:0]});
      3'b011: assert(data_out == {32'h0, data_in[31:0]});
      3'b100: assert(data_out ==          data_in[63:0]);
    endcase
end

The hacked timer violates the first two obligations: it can pulse done during reset or when no valid transfer should exist. The payload obligation adds another guard, requiring every legitimate completion to carry the correct word. Replayed against the contract, Claude Code’s hacked designs are falsified in few seconds. WarpSpeed, by contrast, found a legitimate simplification of the same logic while preserving all contract-required behavior.
‍

In this problem, Claude Code produced an invalid solution by merging multiple counter registers into a single shared representation, which led to incorrect counting behavior. The design still passed the benchmark because no test switched modes mid-run.

The contract closes this gap by construction: on every cycle, the output must match the value of the currently selected counter.

// Six ghost counters advance every cycle; mode_in is FREE.
//        Selection is combinational on the CURRENT cycle (no $past):
case (mode_in)
  BINARY_UP:    assert(o_count == c_up);
  BINARY_DOWN:  assert(o_count == c_dn);
  MODULO_N:     assert(o_count == c_mod);
  JOHNSON:      assert(o_count == c_jn);
  GRAY:         assert(o_count == (c_g ^ (c_g >> 1)));
  RING:         assert(o_count == c_rg);
  default:      assert(o_count == 0);
endcase

Because mode_in is free, the checker can switch modes on any cycle. A single shared register can hold only one mode’s value, so after a mode switch it no longer matches the newly selected counter and the proof fails. As it happens, WarpSpeed found a valid way to achieve similar area savings: a shared counter core with lightweight per-mode decode logic that remains correct on every cycle.

Handling Hard Verification Tasks With Decomposition

Some properties are easy to state but difficult for a formal solver to prove directly. When that happens, WarpSpeed breaks them into smaller properties that are easier to prove but together guarantee the same result. The next two examples come from real optimization tasks in the benchmark.

Consider integer division. Given a dividend a and a positive divisor b, the circuit returns a quotient q and a remainder r. Instead of comparing it against a second divider algorithm (a common verification approach that forces the solver to reason about two implementations) WarpSpeed verifies two simpler properties:

• Identity: q · b + r = a
• Range: 0 ≤ r < b

Together, these uniquely establish the correct result.

WarpSpeed used the same approach for a different RTL optimization problem: optimizing a sorting circuit. Rather than comparing against another sorter, it proved that the output is ordered (out[i] ≤ out[i+1]) and is a permutation of the input (the same values, with the same multiplicities). Together, those properties guarantee that the sequence is correctly sorted.

Using the same formal verification tool and budget, these decomposed checks  remained tractable at proof depths (number of clock cycles) where reference-equivalence comparisons (comparing against another implementation of the same functionality) could no longer complete.

Self-Improvement and Knowledge Propagation

WarpSpeed is a self-improving multi-agent system. It can tackle problems sequentially or in parallel, with agents coordinated by a manager and continuously learning from both their own experience and one another. As agents experiment, they discover which techniques work, how the environment responds, and which actions lead to success or failure. These lessons are continuously distilled and shared across agents, roles, and future iterations, allowing the entire system to improve over time.

The graph below shows how this knowledge propagates through a self-improvement run. Each column represents a RTL-optimization problem, grouped by design family, and each row represents one of five iterations, with time flowing downward. A descending edge means that a lesson learned on one problem was reused by another in the next iteration, so knowledge increasingly cascades through the system.
‍

Across the run, agents repeatedly built on both their own prior experience and lessons learned from other problems, revisiting lessons they had written in earlier iterations 113 times and making 97 cross-problem transfers across 71 distinct problem-to-problem links. Reuse increased as the shared knowledge base grew. Below, we show one concrete example of this cross-problem knowledge transfer.

Cross-Problem Knowledge Sharing Drives Performance Breakthrough

The clearest performance breakthroughs did not come from a single trick, but from combining an idea discovered on one problem with a lesson borrowed from a completely different one.

One such clean example is designing a CRC-32 chip[2]. The original CRC-32 core used 2,527 cells. Working on the problem alone, the agent discovered two optimizations: a complement-domain rewrite, allowing the same register to serve as both the running CRC state and final output, and Paar-style XOR factoring of the CRC computation. Together, these brought the design down to 393 cells, where progress plateaued.

Then, in a later iteration, WarpSpeed imported a lesson from a seemingly unrelated problem: an order-matching engine. There, it had discovered a more efficient way to capture and store an input snapshot. Applying the same structural idea to CRC-32 removed 112 cells, and another round of improvement brought the design to 281 cells, passing WarpSpeed’s full verification stack. An improvement that is more than 30% better than any other competitor solution.

One idea came from CRC arithmetic, the other from a stock-exchange-style matcher. Despite looking unrelated, both share the same underlying pattern: capture data, then process it over time. WarpSpeed recognized and transferred that structure across problem domains.

Conclusions

The right kind of AI systems can design hardware autonomously while maintaining strong correctness guarantees. In this blog, we showed that an AI system can take a natural-language specification, design complex circuits, optimize existing RTL, formally verify its implementations, and carry knowledge from one problem to the next.

This points toward AI systems that can own increasingly large parts of the hardware design - exploring more alternatives, shortening design cycles, reducing engineering costs, and making specialized hardware practical for many more applications.

‍