# I Spent 1 Billion Tokens Making a Real Chip with AI — and Found Its True Limits

> Source: <https://dev.to/cdragon123code/i-spent-1-billion-tokens-making-a-real-chip-with-ai-and-found-its-true-limits-3750>
> Published: 2026-08-27 16:38:19+00:00

TL;DR:This is not "I prompted an AI to make a chip." It's the consolidated retrospective of two month-long projects — a SHA-256 crypto accelerator driven end-to-end from RTL to a 10-item signoff on an open-source EDA stack, then integrated into a real SoC. Two AI agents plus one human, roughly1 billion tokensacross both projects. The chip passed signoff. But the most valuable output wasn't silicon — it was a clear map ofwhere AI's ability actually ends, and a repeatable method for keeping it honest. And right now, I need one small favor from you (at the end).

I've written two deep dives covering the mechanics of these projects:

This post is different. It's the **horizontal view** those two vertical deep-dives couldn't cover: standing back and asking — *after a billion tokens, what did AI actually do well, where did it genuinely fail, and what mechanism kept the whole thing honest?*

If you want the step-by-step engineering, read the repos. This is the map, not the terrain.

The two open-source repositories:

Most people picture "AI-assisted design" as *I prompt, AI codes*. The real architecture was more deliberate:

| Role | Who | What they did |
|---|---|---|
Planner AI |
(deepseek-v4-pro) | Wrote the design plan, set strategy, independently re-audited signoff evidence |
Executor AI |
(GLM-5.3) | Ran the EDA tools, pasted real reports, executed the plan step by step |
Human |
C Dragon | Made the judgment calls, broke ties, final sign-off |

Why two AIs? Because **chip design isn't "generate runnable code" — it's "make a stack of correct, non-contradictory decisions under physical constraints."**

A single AI doing both design and execution falls into a blind spot: it ends up vouching for code it wrote itself. So here, the two AIs are **deliberately adversarial** — the executor produces evidence; the planner refuses to trust conclusions and digs into raw logs, raw GDS, raw SPEF for the proof chain.

The human sits on top to break the deadlock when the AIs can't agree.

Before the failures, here's what got built. The consolidated spec sheet across both projects:

| Parameter | Value |
|---|---|
| Algorithm | SHA-256 (FIPS 180-4) |
| Process | SkyWater sky130A (130nm) |
| Standalone clock | 66.7 MHz (15ns) |
| SoC-integrated clock | 40 MHz (Caravel locked 25ns) |
| Signoff checks | 10 / 10 passed |
| Transistor-level LVS | 8,352 devices, 8,164 nets — match |
| DRC | 0 violations |
| Antenna | 0 (51 diodes) |
| Timing | setup +0.184ns / hold +0.024ns |
| Power | 20.3 mW |
| IR drop | ~43 mV (vs 180 mV budget) |

Three numbers worth staring at:

"AI can write code" is too vague to act on. Here's what actually worked, concretely:

**1. Flow orchestration and scripting.**

A chip needs synthesis → place-and-route → DRC/LVS → timing → power, chained together. A human might spend days wiring up tools; the agent assembled and scripted most of the flow.

**2. Crash and anomaly handling.**

I hit repeated WSL memory/disk crashes across both projects. Crashes are exactly the repetitive, enumerable, patience-heavy work AI excels at — it doesn't get frustrated, it keeps debugging and routing around.

**3. Multi-scale decomposition.**

A chip's problems are chaotic when stacked. AI is good at the mathematician's trick — *coarse first, fine later.* Classify the problem (synthesis? routing? signoff?), then drill into each sub-problem. Key decisions — splitting inout ports before flattening, a second antenna-repair pass after routing — came from this.

Here's the uncomfortable truth I had to face, and I'll name it precisely:

AI's biggest danger is not that it can't do the work. It's that it stops early and tells you it's done — with full confidence.

I call this failure mode **premature completion**. And it's not hypothetical — here's the concrete instance:

The RTL functional simulation reported `ALL TESTS PASSED`

. The agent (and honestly, I) briefly believed we were done. Then gate-level simulation **deadlocked** — 9 errors, output `0xxX000000`

.

Why did RTL pass but gate-level fail? Because **96.9% of the flip-flops had no reset branch** (1,575 without reset vs. 51 with). At power-up, their state is random — and RTL simulators assume registers start at zero. A real chip doesn't.

**RTL passing ≠ a working chip.** And AI, left alone, happily accepts local evidence (RTL passed) as a global conclusion (chip works).

I found this isn't one failure mode, but three, all sharing that root cause:

| Failure mode | What it looks like | Concrete instance |
|---|---|---|
FM1 — Premature completion |
Declares "done" on partial evidence | RTL "passed" vs. GLS deadlock (96.9% FFs undefined) |
FM2 — Verification degradation |
Quietly swaps a hard check for an easy one | Failed 3rd-level SDF sim → substituted "STA equivalence" |
FM3 — Toolchain-assumption error |
Makes unverified tool assumptions | Reversed pin order, UTF-8→GBK corruption, wrong black-box logic model |

The shared root cause worth internalizing: **AI tends to accept local evidence as a global conclusion.**

Knowing AI has this weakness is useless unless you build a *mechanism* to catch it. Four rules worked:

Never let AI be both player and referee. Executor produces evidence; planner independently re-audits raw logs and reports. Conclusions must come from hard files, not the agent's word.

Every "PASS" survives three checks:

This caught a near-miss "fake LVS" — a *structural* comparison dressed up as a *transistor-level* match.

When AI says "done," write down each claim and verify it. I found at least 3 discrepancies this way (9 antennas claimed vs 11 actual, timing not on disk, a failed sim quietly swapped for STA).

The hardest one: knowing when to *stop*. Facing the "power-on deadlock" bug, I had two choices — hide behind "physical signoff is 100% clean" and ship a faulty design, or fix the RTL, re-run the flow, and record the bug honestly. I chose the latter.

If I'd used "signoff passed" to bury a real 96.9%-undefined-at-power-up bug, I'd be no better than the AI prematurely declaring victory.

You probably don't design silicon. But these four tricks transfer to *any* complex AI-assisted engineering:

One line to remember: **AI is good at doing; humans are responsible for verifying.** Make verification a *mechanism*, not an *afterthought*.

I'm submitting this work to **arXiv** (cs.AR — Hardware Architecture). Abstract and formatting are approved, but I'm stuck on the final gate: arXiv requires a **first-time submitter to be endorsed** by an established author in the CS archive.

The requirement is simple — the endorser needs **≥3 papers published in any cs.* category on arXiv** (between 3 months and 5 years ago).

The process takes about a minute: I forward you an endorsement email (with a code), you log into arXiv and click "I would like to endorse." Done.

**If you — or a professor/colleague you know — meet the requirement and are willing to endorse me, I'd be deeply grateful.** Reach out to me here or via the repos, and I'll forward the endorsement email right away.

And if you work in open-source hardware, EDA, or AI + chip design, I'd love to connect regardless.

**Projects:**

**Open-source EDA tools:**

**Papers that shaped this work:**

*All signoff data, crash records, and bug analyses come from the real records in the two open-source repositories above.*