The architecture at a glance: four months, three parts, one end-to-end flow
The last few posts were about the why. This one steps back to the how: Vibe-IC is really three parts, assembled in a deliberate order over about four months. Think of this as the map — the whole picture first, before the next three posts zoom into each part.
The map before the details
So far this series has laid out the reasoning — the bet on handing the whole chip-design flow to AI, the first-principles view that logical work eventually gets done by AI, and the ecosystem stance where open and commercial tools coexist. This post switches to the concrete question: how is the thing actually built?
The answer is three parts, put together in a specific sequence over roughly four months. This is the spine post. I'll keep it high-level — one section per part — and then each part gets its own deep-dive in the three posts that follow. If you only remember one diagram from the whole series, I'd like it to be this one.
The order was the whole strategy
The four months broke down into three phases of work, and the order was not incidental — it was the strategy:
- Build the flow. Lay down a complete, professional Phase → Stage → Step pipeline first.
- Front-end convergence. Use benchmarks to validate and tighten the Spec → RTL translation until it reliably produces good RTL.
- Mid-and-back-end convergence. Fork and complete the open-source EDA tools so everything after RTL runs through to a real result.
Why this order and not another? Because you can't converge a flow you haven't built yet, and you can't sensibly push work into the back-end EDA tools while the front end still can't reliably hand you good RTL. So: skeleton first, then make the front end steady, then complete the back end so the whole thing runs end to end. Each part depends on the one before it holding still.
Part 1 — Building the flow
The first part is the flow itself: a complete, professional pipeline with explicit Phase → Stage → Step structure. Because the goal is AI-Native, end-to-end IC design, getting the flow right is the crucial first move — everything else hangs off it. After a lot of adjusting, adding steps, and optimizing, what exists today is one main line plus two branches — Analog and Mixed-mode — that interleave into it when a design needs them.
Structurally that's 3 Phases · 5 Stages · 63 Steps (the digital main line being 44 of them): Phase 1 folds intent into a layered set of L1–L27 design documents; Phase 2 goes spec → RTL → verification; Phase 3 runs the EDA back end down to GDS and on to production test. One line: the flow is the skeleton the other two parts hang on. The deep-dive — including the ATLAS method behind it — is the next post.
Part 2 — Front-end convergence
The second part focuses on the front-end transformation: Spec → RTL. This is validated the hard way — with a lot of benchmarking (VerilogEval-V2, VE-Human, RTLLM, plus broader and harder real-world projects) run over and over. Three working principles hold it together:
- Score-optimize. Keep tightening the front end so that, apart from a very small set of genuine floors, everything passes.
- Program-First, AI-Backup. Run two paths — one program-logic path, one AI path — cross-check them against each other, and converge as much as possible into a Program or a Program Gate.
- IC-expert-agent extraction. Distill accumulated experience into the IC-expert agent: whatever can be programmed becomes a program; the conventions that can't be programmed go into the IC-expert agent as reusable rules.
One line: make the front door reliably produce the right RTL. The deep-dive is post 6.
Part 3 — Mid-and-back-end convergence
The third part starts where RTL ends and enters the EDA tools proper — PnR, CTS, DRC, LVS, STA, IR, and the analog side. There are many small, unfamiliar steps here, and every one of them has to run and pass verification. The biggest challenge is that the existing open-source tools have gaps that can stall the flow, so it never reaches a production-ready result.
That is exactly why I decided to fork and optimize these open-source EDA tools myself — to complete the open-source part of the flow so it reaches sign-off grade and the whole pipeline can run all the way through. The stance here is simple and non-adversarial: completing the open side isn't about competing with anyone. If a commercial EDA vendor wants to plug in and become a paid part of the ecosystem, that's just as welcome. One line: make every step after RTL actually pass. The deep-dive is post 7.
The three parts on one page
Here's the whole map in a single table — the spine of the next three posts:
| Part | Focus | What "done" looks like | Deep-dive |
|---|---|---|---|
| 1 · Build the flow | Define a complete Phase → Stage → Step pipeline | Main line + Analog + Mixed-mode each have a coordinate on the map | Post 5 |
| 2 · Front-end convergence | Spec → RTL | Benchmarks all pass (bar a tiny floor); the two paths converge into programs | Post 6 |
| 3 · Mid/back-end convergence | RTL → GDS, the EDA tools | Open tools completed to sign-off grade; everything after RTL runs through | Post 7 |
Reading it top to bottom is also reading it in build order: I couldn't tune the front end before the flow existed, and I couldn't complete the back end before the front end was steady. As a software person new to this flow, that dependency chain is the single clearest thing I learned about how to actually get a system like this to stand up.
That's the spine. The next three posts go deep on each part in turn — Part 1, how the flow itself was built (the ATLAS method); Part 2, how benchmarks ground the front end to a clean pass; and Part 3, how the open-source EDA tools got completed so that every step after RTL runs through. Next up: Part 1 — where the flow comes from.