An autonomous AI agent designed a tape-out-ready RISC-V CPU end-to-end in about 12 hours, producing a VerCore with a CoreMark of 3261 (comparable to a 2011 Intel Celeron) using the academic ASAP7 process; the result demonstrates AI-driven automation of substantial parts of chip design, though only on an academic node and a single project.

Main Finding

Design Conductor (DC), an autonomous multi-agent system that leverages frontier LLM capabilities, autonomously designed a complete RV32I+ZMMUL RISC‑V CPU (“VerCore”) from a 219‑word requirements document to tape‑out‑ready GDSII in ~12 hours. The resulting microarchitecture met timing at 1.48 GHz, achieved a CoreMark score of 3,261 (roughly comparable to a mid‑2011 Intel Celeron SU2300), and produced layout (GDSII) using an OpenROAD flow on the ASAP7 (research) 7nm PDK. The VerCore RTL and scripts to reproduce the GDSII will be released publicly.

Key Points

• Autonomous end‑to‑end result: DC handled architecture, RTL, testbench, verification, synthesis, place & route, parasitics, PPA closure, and GDSII generation without human intervention.
• Performance & metrics:
  • Timing closure: 1.48 GHz (target ~1.6 GHz; achieved 1.48 GHz).
  • CoreMark: 3,261.
  • Design footprint: GDSII plots shown (~70 µm × 70 µm).
• Design specifics:
  • ISA: RV32I + ZMMUL (no compressed instructions).
  • Microarchitecture: 5‑stage, in‑order, single‑issue pipeline (IF, ID, EX, MEM, WB); register file implemented with flip‑flops; CPI target ≤ 1.5.
  • Cache interfaces and handshake behaviors implemented per requirement.
• DC architecture and capabilities:
  • Long‑horizon execution and persistent memory to manage multi‑billion–token workflows and evolving “living” design documents.
  • Context management to orchestrate LLM sessions and avoid context window limitations.
  • Modular subagents for design planning, module implementation, root‑cause analysis, integration, and PPA closure.
  • Tool integrations: Spike (ISA simulator), RISC‑V toolchain, OpenROAD flow, ASAP7 PDK, standard EDA tool outputs (VCDs, reports).
• Verification approach:
  • Spike‑based cycle‑accurate architectural checking via a Spike-driven testbench.
  • VCD→CSV conversion and automated Python analysis to compare expected vs actual register/memory traces; iterative debug and RTL fixes.
  • Module‑level testbenches before integration; iterative updates after place & route timing feedback.
• Infrastructure demands: large storage and RAM (VCD traces hundreds of GBs), multiple execution environments (VMs/containers), and scalable, reliable distributed infra.
• Novelty claim: first autonomous agent to go from spec to GDSII for a complete CPU (per authors).

Data & Methods

• Inputs:
  • Single 219‑word requirements doc specifying interfaces, pipeline style, timing targets, CPI target, PDK and flow (ASAP7, OpenROAD), testing expectations (Spike), and I/O timing assumptions.
  • Access to Spike, RISC‑V ISA docs, RISC‑V GNU toolchain, and OpenROAD/ASAP7 flow.
• Workflow (high level):
• Requirements analysis → generate initial design proposal (living document).
• Detailed microarchitecture definition (5‑stage pipeline, hazards, forwarding, multiplier integration).
• Per‑module RTL implementation with module testbenches.
• Integration into system testbench that runs ELF programs under Spike and the DUT.
• Debug via VCD traces: vcd2csv conversion, automated Python scripts to extract register writes and compare to expected Spike trace; root‑cause analysis and RTL fixes.
• PPA closure loop: synthesis → place & route → parasitics extraction → timing reports → RTL & constraint updates → rerun flow; design updated in response to final timing.
• Generate final OpenROAD scripts → produce GDSII.
• Tools & formats:
  • Spike (ISA model), standard RISC‑V toolchain for test binaries.
  • OpenROAD flow for physical implementation and GDSII generation.
  • ASAP7 research PDK for physical modeling.
  • VCD waveform outputs, parsed to CSV for automated inspection (Pandas + Python scripts).
• Outputs & artifacts:
  • Verified VerCore RTL, module testbenches, integration testbench, OpenROAD scripts, timing/area reports, and GDSII layout files. Authors state RTL + scripts will be publicly available.
• Timeline & compute:
  • End‑to‑end autonomous run in ~12 hours (authors’ reported wall‑clock for the automated run). Significant compute and storage resources implied (large VCDs, multiple LLM sessions, EDA runs).

Implications for AI Economics

• Productivity and cost structure shifts:
  • Automation of large portions of chip design could materially reduce engineering labor and calendar time for many classes of designs, lowering fixed engineering costs and accelerating product cycles.
  • If generalized, this could reduce barriers to entry for specialized and low‑volume chips (more economically viable niche/custom accelerators), shifting market dynamics away from a small set of incumbents for many segments.
  • However, capital costs tied to masksets, fabs, and actual silicon manufacturing remain major constraints; automation primarily reduces design (non‑fab) costs.
• Labor market effects:
  • Routine, repetitive verification, testbench writing, and many low‑level RTL tasks may be automated, decreasing demand for certain implementation roles.
  • New labor demand will likely emerge for oversight, model‑validation, high‑risk verification, integration of IP/PDK/legal review, and management of autonomous design fleets.
  • Upskilling toward supervising/qualifying model outputs and focusing on higher‑level architecture choices will be valuable.
• Value capture and business models:
  • Value may shift toward proprietary PDKs, foundry capacity, hard IP blocks, and tooling ecosystems (EDA vendors and model providers). Firms may monetize automated flows, curated design libraries, and verification services.
  • Fabless startups could scale faster with lower engineering bills but will still need capital for tape‑outs; one plausible equilibrium is more designs but persistent bottlenecks in multi‑million dollar mask/fab costs, possibly increasing demand for multi‑project wafer services or alternative packaging/OSAT models.
• Market competition & innovation:
  • Faster design iteration may accelerate innovation cycles and proliferation of domain‑specific chips (e.g., ML accelerators), increasing competition and lowering costs for specialized hardware.
  • The democratization of design tools may enable more experimentation, but incumbents with deep IP portfolios and vertical fab relationships retain strategic advantages.
• Risk, quality, and regulatory considerations:
  • Autonomous design agents must be validated rigorously—errors in hardware can be costly and dangerous. Independent verification, formal proofs, and conservative testing regimes will be economically valuable services.
  • IP, export control, and licensing issues could complicate deployment—automated generation of designs that infringe IP or violate export rules poses legal risk and economic friction.
• Infrastructure & model‑cost economics:
  • Running such end‑to‑end automation requires substantial compute, storage, and EDA license/integration costs. Providers that bundle compute + verified model stacks may capture value.
  • Improvements in frontier models (accuracy, long‑horizon reasoning, tool use) and tighter tool integrations will amplify economic impacts.
• Uncertainties & caveats:
  • Single demonstration: results are promising but from one reported system and one design class. Generalization to complex high‑performance designs, advanced nodes with proprietary PDKs, and production silicon remains to be proven.
  • Fabrication not demonstrated: producing layout (GDSII) is necessary but not sufficient—tape‑out and silicon bring additional verification, yield, and packaging costs.
  • Use of research PDK (ASAP7) and open flows may not reflect constraints of commercial PDKs and proprietary EDA toolchains; economics differ when commercial tool licensing and foundry rules apply.
• Net economic takeaway:
  • Autonomous design agents like DC could lower the marginal cost and time of many chip designs, enabling more entrants and faster innovation, while shifting economic value toward fab capacity, IP, high‑assurance verification, and model/tool providers. The extent of disruption depends on generalizability, model/tool maturity, and how remaining capital and regulatory constraints evolve.