An agent optimised for hardware development: trade-off exploration.

What it does

Give it one high-level spec. A LangGraph agent chooses which architectures to explore, a classic optimiser searches them on tested models, and the agent reads the results, decides what to try next, and picks the design. That one spec then goes down the fidelity ladder: the design inside a SimPy model of its system and a cycle-accurate model of its interface, RTL generated and simulated in two simulators, FPGA synthesis and place and route, gate-level simulation of the netlist, synthesis on a second target (standard cells on the open sky130 PDK), and back-annotation of the measurements into the cost model, each level offering its own power, performance and area view, with regression tests against the golden model at every level.

The pitch

1. Explore before you optimise. Exploration finds the critical 3% worth optimising: the right architecture for this spec, or the proof that none exists.
2. The LLM never produces a number. It chooses families, ranges and next steps; deterministic code computes every figure, labelled exact (bit-accurate golden model), estimate (calibrated cost model), measured or simulated (the system model).
3. Software and hardware, one engineer. Built with LangGraph, Python, TypeScript, tests and CI by an engineer with more than 25 years in hardware: FPGA and RTL, SoC, power, signal and power integrity, PCB and DSP. About

What the eval found

The CORDIC sin/cos case study has 635,040 possible designs, few enough to score every one, so each run is graded against the exact answer. Milestone 1 (48 runs with real models) found a split: the agent was the better selector, and NSGA-II the better front-mapper, because the agents dived at the spec's corner and stopped early. Milestone 2 (60 runs, five seeds) gave the agent a way to map the whole trade-off curve, and closed the gap: every model now covers 0.96–1.09× NSGA-II's hypervolume on every feasible spec (M1: as little as 0.18×), while still selecting a better design than NSGA-II in 8 of the 9 model-and-spec cells. It got worse in places: Qwen lost on high_precision (one bad seed), DeepSeek's selection slipped, and the agent now always spends the full budget. The M2 results lead with those.

Milestone 3 put the design inside its system. On a motor-control spec whose 32 requests per tick must all be back within 0.44 µs, only the simulation finds the right design: the throughput-only view, the L1 bound and even peak-rate sizing all pick a smaller one that misses the deadline by 1.5%. It also measured a free-form campaign agent (LangChain Deep Agents) over the structured graph, and reports plainly that it gained nothing at 1.44–2.25× the cost, so it stays experimental. Milestone 3's results are on the results page.

Milestone 4, the last, took the same RTL to standard cells on the open sky130 PDK (post-synthesis, no place and route) and ran several structured graphs on one spec as a fleet, orchestrated by code. The family ranking is the same on both targets, but the ASIC wants shallower pipelining. Its losses come first: the fleet mapped the trade-off curve worse than one graph (higher hypervolume in only 18 of 55 paired runs), and the ASIC model's winner for a control-loop spec misses its deadline when measured (72.2 MHz against an estimated 82.5). With Qwen the fixed fleet did pick better designs (lower regret in 22 of 25 pairs), on one model and with a timing caveat. Milestone 4's results come first on the results page, and the final write-up tells the whole project in one place. For a hardware team weighs what it would and would not do for a company that builds its own hardware.

Measured, not just estimated. The ground truth's winners were generated as RTL, verified bit for bit in two simulators and at the gate level, and synthesised: the repository's open-source flow has 39 measured points and Vivado 2025.2 14 designs. Refitting the cost model to them changes no spec's winner, and on high_precision, where the margin is thinnest, routed timing confirms the choice. See the measurements.

The infeasible spec. Asked for 400 MSPS, every model on every seed of both milestones declared the spec infeasible itself and named throughput as the binding constraint. The exhaustive grid agrees: the fastest design anywhere reaches 291.5 MSPSestimate.

What it costs to run

The price of the LLM is part of the result. In M2, a complete exploration of one spec cost between $0.0073 and $0.064 per run depending on the model, and took 27.7 s to 89.1 s on average; all 60 runs cost $1.65 provider-reported. In M1, turning Qwen3.8-27B's reasoning off made it about 7.8× cheaper per run and 15× faster by wall-clock.

Labour-saving, round the clock. Each run is an independent, checkpointed LangGraph thread, so several agents can run 24/7, each evaluating a real design decision; the M2 eval above is 60 of them, up to 4 at once. That is what the architecture enables, not a measured round-the-clock fleet. Projection, from the measured M2 means: one Sonnet 5.5 agent running back to back for a day would finish about 3,120 explorations for about $198.89 (ignoring rate limits).

The ladder, as of commit 80415c6

• L0 Spec intakelive (M1)natural language or YAML in, a validated Spec out; a human confirms it. Check: the Spec schema validates it; interrupt() asks a human to approve, edit or reject.
• L1 Analytical explorationlive (M1)the LLM picks families and ranges; NSGA-II searches them on fast models. Check: the golden model is bit-exact against the reference RTL on all 65,536 input angles (Icarus, in CI).
• SYS System-level simulation (SimPy)live (M3)the candidate inside a SimPy model of its system (a DDS feeding a mixer, a control loop, a bursty request stream), clocked at its estimated Fmax; every L1-feasible design of a run is simulated. Check: exhaustive ground truth for 3 system specs (1,092 distinct timing tuples cover all 635,040 designs); the winner changes on 2 of them, and on the ASIC system spec (M4: 8,533 designs pass the bound, 7,898 the simulation); the device is checked request by request against the cycle model.
• L2 Cycle-level simulationlive (M3)a cycle-accurate model of each family's interface (ready, valid, latency, initiation interval), edge by edge. Check: against the generated RTL, cycle for cycle: 48/48 bursty traces identical in Icarus Verilog 12.0 and Verilator 5.020 (28,424 clock edges).
• L3 RTL simulationlive (M2)one generator turns any explored design into parametrised SystemVerilog, simulated in Icarus Verilog 12.0 and Verilator 5.020. Check: every output code against the golden model: 47 configurations in both simulators, 0 mismatches (exhaustive up to W = 16); 7/7 SymbiYosys proofs at W = 8.
• L4 Synthesislive (M2)Yosys + nextpnr-xilinx synthesis and place-and-route on the anchors' Artix-7 part, and Vivado 2025.2. Check: 39 open-source points and 14 Vivado designs, each compared with the L1 estimate; the synthesised netlists are simulated at the gate level.
• GL Gate-level simulation of the netlistlive (M2)the Yosys-mapped netlist, simulated with the vendor cell models (zero-delay). Check: every output code against the golden model: 22 runs, 0 mismatches.
• ASIC Synthesis on sky130 (standard cells)live (M4)the same generated RTL through Yosys 0.33 + OpenSTA 3.1.0 on sky130_fd_sc_hd (typical corner, 25 °C, 1.80 V, 10 ns clock): post-synthesis with a wire-load model, no place and route. Check: CI re-synthesises all 57 calibration points and requires identical numbers; 9 held-out designs never fitted: area within 5% on 9/9, Fmax -14.9% to +39.6%.
• L5 Back-annotationlive (M2)compare measured with L1, refit the cost model per tool, flag a winner change and (M3) re-explore under the refit. Check: the ground truth is recomputed under each refit: no spec's winner changes.

Badges follow the roadmap in the repository's README at 80415c6, where M1, M2, M3, M4 are done: every planned milestone. The README's L2 covers both the cycle-accurate model and the SimPy system models, shown here as two rungs; its L4 has an ASIC row (sky130, post-synthesis only: an open-PDK estimate, not silicon).