ChipOmni uses engineering checks to guide AI chip design

Can an AI system keep a chip-design project moving when its first answers fail? ChipOmni addresses that question by connecting language models to engineering software, then using failed checks to guide repairs. In a preprint posted on November 9, 2026, Pengkun Wang and colleagues report improvements across several electronic-design benchmarks and a processor-based chip layout completed without human intervention after initialization. The design has not been fabricated or tested in silicon.

A workflow built around feedback

Electronic design automation, or EDA, already automates many individual engineering tasks. The coordination remains difficult: a written specification must become circuit descriptions, simulations, verification checks and eventually a physical layout. These representations use different tools, and success at one stage does not guarantee success at the next.

ChipOmni divides that coordination among four software agents. PlanExec makes plans and performs design actions. Validator runs external engineering checks and derives stage-specific acceptance criteria from the specification. DebugMemory examines failures and produces targeted repair instructions. ContextOptimizer compresses the growing execution history while retaining relevant constraints, results and lessons.

The framework also retrieves engineering knowledge from a collection the authors describe as containing more than 10,000 textbooks and technical documents, alongside software manuals, libraries and reusable skills. Its central mechanism is not simply generating more code: it repeatedly generates, executes, diagnoses and revises designs.

One example involved an oscillator that initially settled to a constant voltage rather than oscillating. The system changed the feedback connections and resistance-capacitance network, including increasing the capacitance at each stage. The revised circuit produced sustained oscillation in simulation and passed the configured checks.

What the benchmarks showed

The researchers tested analog circuits, digital hardware descriptions, testbenches and formal assertions. A testbench exercises a design in simulation; an assertion states a property that verification software can check.

On AnalogCoder-Pro, ChipOmni produced at least one successful solution for each of 30 tasks with each of three underlying language models. That does not mean every attempt succeeded. With GPT-5, for example, the reported Pass@1 score increased from 87.90% for the baseline to 92.67% with ChipOmni. The analog outputs underwent checks including operating-point analysis and task-specific simulations.

Digital results also improved. On the 50-design RTLLM2 benchmark, using DeepSeek-V4-Pro, functional Pass@1 rose by 24.8 percentage points over the corresponding backbone model. On VerilogEval v2, generated hardware descriptions were compiled and tested against official testbenches, with at most one feedback-based refinement.

The results also expose the distance between producing valid code and producing useful verification. On AutoBench, ChipOmni’s testbench compilation Pass@1 reached 97.56%. Its score for agreeing with a reference testbench when detecting deliberately faulty designs was much lower, at 50.48%, although that improved on the baseline’s 44.81%.

Nor were gains universal. For expert-written properties in FVEval, strict full equivalence under JasperGold fell from 82.2% to 78.1%. Machine-generated property descriptions showed stronger improvements. These differences matter: textual similarity, valid syntax and matching the intended behavior are distinct achievements.

Experiments removing individual mechanisms found that repair supplied the largest gain among the mechanisms tested alone. Combining repair, prior knowledge and context evolution performed best in the evaluated configurations.

From specification to physical layout

The longest demonstration began with a minimal RISC-V processor, expanded it into a five-stage processor, and integrated memory and peripherals into a small system-on-chip. ChipOmni then coordinated physical implementation through a GDSII file—the format used to describe chip-layout geometry.

Across 16 planner sessions, the system addressed problems including syntax errors, inconsistent hardware assignments, GPIO mismatches and physical-design configuration issues. The authors report that it resolved 12 recorded problems and passed seven evaluation gates.

The final implementation contained 224,181 non-filler standard-cell instances and had a reported die area of 5.42 square millimetres. Timing checks met the 25-megahertz target across nine analysed corners, representing different operating or manufacturing conditions. Physical checks reported no design-rule violations or layout-versus-schematic errors.

What remains unproven

Those results establish a reported software-verified layout, not a demonstrated working chip. The 63.7-milliwatt power figure came from engineering analysis, not physical measurement. Fabrication and silicon testing remain necessary to assess actual functionality and performance.

The framework also depends on the quality of its checks. Requirements that are missing, difficult to formalize or poorly covered by tests may escape its repair loop. The authors acknowledge that permission boundaries, unintended actions and execution auditing have not been systematically evaluated. They describe public code and evaluation-platform release as future work.

ChipOmni therefore offers evidence for coordinating design through executable feedback, while leaving open how reliably that approach extends beyond the tested tasks and into manufactured hardware.