Design Conductor (DC) for Autonomous IC Design

• Design Conductor (DC) is a multi-agent system that automates the entire digital circuit design flow from high-level requirements to GDSII using LLMs.
• It integrates specialized agents for microarchitecture exploration, RTL generation, verification, and physical design, ensuring iterative PPA optimization.
• Empirical demonstrations show DC’s ability to scale from RISC-V CPUs to complex inference accelerators, highlighting significant improvements in resource efficiency and design closure.

Design Conductor (DC) comprises a class of autonomous agent systems designed to automate the conception, implementation, verification, and backend closure of digital integrated circuits and accelerators, from high-level requirements to GDSII. It leverages LLMs within a modular orchestration harness, enabling agent-driven microarchitectural exploration, RTL generation, functional and timing verification, physical design integration, and full workflow iteration, with minimal human input. DC systems have demonstrated end-to-end success on industry-scale digital designs, ranging from RISC-V CPUs to complex inference accelerators, and their empirical scaling characteristics and methodology are now foundational for LLM-driven semiconductor workflows (Team et al., 6 Feb 2026, Team et al., 6 May 2026).

1. Agent-Based System Architecture

DC is organized as a multi-agent harness, typically cloud-native, in which a supervisory Orchestrator agent decomposes system-level requirements into a dynamic task graph. The Orchestrator parses user-provided concept-level specifications, partitions the design flow into macro-phases (e.g., architecture exploration, module microarchitecture, verification, physical design), and instantiates dedicated subagents with clear functional demarcation:

• Architecture Agent: Responsible for first-principles reasoning (pipeline depth, floorplanning, compute partitioning), exploration of design alternatives, and spec generation.
• RTL Generation Agent: Writes synthesizable Verilog, parameterized per architectural directives, and manages module hierarchy.
• Verification Agent: Constructs testbenches (SystemVerilog, Python golden references), drives automated debugging loops, and ensures alignment with external simulators.
• Timing and Physical Design Agent: Interacts with EDA backends (Vivado, OpenROAD), assesses timing slacks, and feeds closure constraints.
• Integration Agent: Orchestrates system-level simulation, regression testing, and manages inter-module interfaces.

The system communicates via structured JSON messages, with a persistent “Design Memory” (caching tables, floorplans, validated modules) that improves token-efficiency and context recall, enabling DC to maintain architectural coherence across multi-day design runs (Team et al., 6 May 2026).

2. Autonomous End-to-End Design Methodology

DC procedures follow a deterministic, layered composition. From a free-form requirements document, the flow comprises:

1. Specification Extraction: The Requirement Parser LLM extracts ISA, timing, area, and toolchain parameters, formalizing inputs for downstream agents.
2. Microarchitecture Exploration: The microarchitecture subagent unfolds candidate pipelines, explores scheduling and forwarding schemes, scores each proposal, and annotates critical-path and PPA (performance, power, area) implications.
3. RTL Implementation: The RTL agent emits modular, synthesizable code for all pipeline stages, central control, and critical compute blocks (multiplier, register file, etc.), applying code-style and interface standardization across the design.
4. Testbench Generation and Debug: Module- and top-level testbenches are auto-generated; system-level simulation uses architectural models (e.g., RISC-V “Spike” traces) to fully exercise functional equivalence, with mismatches analyzed by VCD→CSV trace-diffing and iterative re-simulation.
5. Backend Tool Integration: The physical flow subagent manages EDA tool execution (synthesis, P&R, timing), parses output reports, and invokes further microarchitectural or RTL optimization when closure is not achieved.
6. Iterative PPA Optimization: Cost functions combining negative F_max, area, power, and slack penalties are constructed. The system iterates design refinements using EDA-derived metrics, converging to constraint satisfaction.

A high-level pseudocode abstraction of the core flow is:

function run_design_conductor(spec_doc): reqs = parse_requirements(spec_doc) microarch = propose_microarchitecture(reqs) while not microarch.approved: microarch = refine_microarchitecture(microarch, reqs) rtl = generate_rtl(microarch) module_tests = generate_module_testbenches(rtl) for tb in module_tests: run_simulation(tb) if failure: rtl = debug_and_fix(rtl, tb) dut_tb = generate_system_testbench(rtl) run_simulation(dut_tb) while functional_mismatch: rtl = debug_and_fix(rtl, dut_tb) run_simulation(dut_tb) backend_results = run_backend_flow(rtl) if not meets_timing(backend_results, reqs): rtl, microarch = optimize_for_timing(rtl, microarch, backend_results) goto module_tests emit_gdsII(rtl) return backend_results

(Team et al., 6 Feb 2026)

3. Empirical Demonstrations and Scaling Results

RISC-V CPU (VerCore; DC 1.0)

• Full 5-stage, in-order, Linux-capable RISC-V CPU (RV32I+ZMMUL) synthesized and closed at F_max = 1.48 GHz, area 2809 µm² (ASAP7 PDK).
• End-to-end flow, from 219-word requirements doc to tapeout-ready GDSII, completed in ~12 hours.
• CoreMark score: 3261, closely matching historical CPUs (Intel Celeron SU2300, 1.2 GHz) in single-threaded performance.
• RTL corrections and architectural optimizations driven directly by EDA output analysis (VCD traces, timing slack reports). (Team et al., 6 Feb 2026)

TurboQuant LLM Inference Accelerator (VerTQ; DC 2.0)

• Autonomous assembly of a 240-stage, 8-pipe attention accelerator with hard-wired TurboQuant support and FlashAttention softmax.
• System size: ~500 k lines RTL, resource use: 5,129 FP16/FP32 units, covers 5.7 mm² in TSMC 16FF for an 8-way engine.
• Pipeline end-to-end latency: 1.92 µs at 125 MHz; throughput of 4.2M queries/s achieved across 8 parallel attention engines.
• Compression: 4.3x KV-cache reduction with bit-accurate (≤1e-4 RMSE) outputs versus Python FP32 baseline.
• System built and closed—in terms of spec, integration, functional verification, and timing—in 80 hours, handling a workload 80x larger than the original RISC-V demo.
• Empirical cost breakdown: ~2/3 of resource usage is consumed in high-level module integration and closure phases. (Team et al., 6 May 2026)

4. Key Advances in Design Conductor 2.0

DC 2.0 introduces multiple algorithmic and harness improvements:

• Persistent Memory and Context Reuse: Avoids redundant LLM computation by caching all intermediate results, resulting in scalable token-usage even for >500k-line projects.
• Spec-to-Layout Autonomy: The system is capable of fully self-generating detailed internal spec documents (microarchitecture tables, timing budgets), decoupling human involvement from both low-level coding and interface definition.
• First-Principles Reasoning: Architect agents are empowered to design new compute structures (e.g., fifth-order Taylor expansion for exponentiation) with custom pipelining for timing-critical datapaths (e.g., minimal critical path for exp(-x), optimized multi-die spans).
• Closed-Loop PPA Optimization: Integration of true physically extracted timing and resource closure into the design cycle enables system agents to directly generate, interpret, and update code based on backend P&R feedback, mimicking expert human workflow. (Team et al., 6 May 2026)

5. Workflow Limitations and Human Interaction

While DC demonstrates strong autonomy, several limitations are reported:

• For trivial metric extraction, the agent may re-process the entire design context, bringing inefficiencies for query handling.
• Suboptimal decisions may occur in code-level vs. backend-tool fix selection, where simple script tweaks would outperform RTL rewriting.
• Targeting overly aggressive clock rates or pipeline depths can produce unphysical or impractical backends that require iteration.
• Final review, sign-off, and complex PPA constraint formalization remain partially human-mediated. (Team et al., 6 May 2026, Team et al., 6 Feb 2026)

6. Broader Impact and Future Directions

DC systems have established a practical template for autonomous hardware generation, demonstrating that LLM-driven agent harnesses with modular, memory-augmented orchestration can reliably produce complex digital systems by entirely data-driven processes, tightly coupled to formal EDA outputs. Major future directions include:

• Enriching front-end hardware pretraining for LLMs with focus on event-driven semantics and both functional and timing correctness.
• Expanding DC flows to encompass out-of-order pipelines, full SoC integration, and analog/mixed-signal co-design.
• Embedding differentiable cost/PPA models for microarchitectural search acceleration.
• Closing the loop on end-to-end sign-off with automated PPA constraint generation. (Team et al., 6 Feb 2026, Team et al., 6 May 2026)

7. Summary of Empirical Scaling and Token Usage

A normalized scaling table from DC's reported experiments:

Design	Relative Tokens	Relative Wall-Clock
VerCore (1.0)	1.0×	1.0×
FP32 Add/Sub	2.1×	0.75×
In-Switch Allreduce	0.8×	0.3×
AES Encryptor	4×	4×
VerTQ (TurboQuant)	12×	6.7×

Cost fraction by workflow phase (VerTQ, dollar-normalized):

• Architecture: 6.3%
• Low-level modules: 28.2%
• High-level modules: 32.6%
• Final integration & closure: 32.9%

These empirical results confirm that workload scaling is sublinear in runtime due to persistent memory and coordinated subagent decomposition, but module integration and backend cycles dominate computational cost for complex systems (Team et al., 6 May 2026).