Part 1 — Building the flow: Phase / Stage / Step, main line + analog + mixed-signal (the ATLAS method)

First, how it was built: the ATLAS method

Before I lay out the flow, let me say what method I used to build it — otherwise the fairly complete table further down will look like it appeared out of thin air. The method is called ATLAS, and at its core it's two things: AI-Native (let an agent be the front door and drive the whole path) and Program-First (anything that can be written as a program gets frozen into deterministic code, rather than leaning on the AI's in-the-moment judgment). ATLAS is a domain-agnostic method; Vibe-IC is what I get when I point it at IC design.

ATLAS is five stages that happen to spell atlas. Note it has two A's — the first is AI-Native, the fourth is Automate:

Its spirit is: first get the whole path running with the AI in the lead, then lock down the certain parts one cell at a time. The fourth stage, Automate, I call "the Ratchet" — it only moves forward: every time I successfully turn a piece of "AI judgment" into deterministic code, it stays in the program layer for good, and next time I don't have to bet on the model's mood. And for the corners that genuinely can't be fully frozen, I don't pretend they aren't there — I leave an AI Skill as a graceful backstop (Skill-back), so the whole path still runs to the end. The flow this post builds is what one pass of ATLAS produces.

The shape of the flow: 3 Phases, 5 Stages, 63 Steps

Vibe-IC's skeleton is three big phases. The official framing is 3 Phases · 5 Stages · 63 Steps. That 63 adds up like this: 44 digital main-line steps (step 1–44), plus the cross-stage D1–D5 and P0, plus analog A1–A9 and mixed-signal M1–M4 — 5 + 1 + 44 + 9 + 4 = 63. Most steps only wake up when they're actually needed: a pure-digital design automatically skips the analog and mixed-signal tracks.

There's exactly one way in, and that's Phase 1 — which is what AI-Native looks like in the concrete: the front door isn't a form, it's an agent. You describe your design intent in natural language, and from that moment the agent takes the lead and ingests it. Whether you arrive with a stack of datasheets (Path A) or with just one sentence — or even just a conversation (Path B) — everything converges onto the same handoff before anything goes further. There is no "skip Phase 1 and start writing code" entrance.

Phase 1: turning "one sentence" into L1–L27 layered design docs

Phase 1's output is a set of layered L-docs (JSON). This is the whole design's universal handoff — Phase 2 isn't allowed to start without it; a gate hard-requires generated_docs/L*.json to exist before a single line of RTL may be touched. These docs refine from the top-level external intent all the way down to an implementable spec; the full set is L1–L27 (L1–L13 are the core layers, L14–L27 are advanced and optional). The first 13 layers:

Why break it down this finely? Because every port of every submodule should be defined in exactly one place — L9, the integration spec, has to be pinned down before any RTL. That was my first hard-won lesson: I initially tried to have several agents write RTL in parallel, and they each named the submodule ports their own way and didn't line up. So the rule now is "a single agent produces the RTL, L9 comes before RTL, no stub shell modules." The layering isn't just for learning — it's the foundation the whole system stands on.

Phase 2: RTL → lint → sim → formal → FPGA

With the L-docs in hand, Phase 2 turns them into hardware that actually runs. The trunk is steps 1 through 6:

1. Spec-to-RTL — the one step on the whole path that must lean on AI (there's no deterministic checker for natural-language-to-RTL); but what it produces is verified all the way down by everything below it.
2. Lint — RTL hygiene. There's a subtle line here: the gate only blocks genuine synthesis hazards (undriven nets and the like); stylistic observations are recorded but not blocked — because third-party catalog IP legitimately writes code that way, and hard-blocking it would just kill the flow.
3. CDC/RDC — clock-domain and reset-domain crossing checks.
4. Simulation — cocotb + iverilog run the testbench, and coverage is measured, not the AI saying "about 95%." Whatever can be measured gets actually measured.
5. Formal — SymbiYosys for formal verification. all_proved is only a claim, not a proof; so an evidence-chain gate confirms there's a really-elaboratable .sby and a genuinely PASSing transcript before it's accepted.
6. Early FPGA prototype — synthesized to a .sof, burned onto the board, actually running on hardware.

Phase 3: synth → STA → DFT → PnR → DRC/LVS → GDS

Phase 3 is the back end, and the longest stretch — the trunk runs from step 7 all the way to 44, covering synthesis, timing, testability, physical design, and sign-off. This stretch runs on an EDA toolchain, and every step has its corresponding tool:

A few ordering details I had no intuition for at first and only understood later: CTS (clock-tree synthesis) comes before routing — step 19 is CTS, step 21 is routing, because the clock tree has to be laid down first so routing knows what to route around. And there's a step 18 I find clever: after placement and before CTS, it proactively sprinkles in a batch of spare cells marked dont_touch, as an ECO budget for future metal-only bug fixes — and every later optimization and the metal fill are forbidden from eating them, with a dedicated gate watching them all the way to GDS.

Two side tracks: analog A1–A9 and mixed-signal M1–M4

A pure-digital design just takes the path above. The moment a project has an analog block (an analog_block_list.json exists), two more tracks interleave in.

Analog A1–A9: extract the analog spec from Phase 1 → pick a topology → produce a SPICE netlist + sizing → run a PVT corner sweep → lay it out → each block finishes its own DRC/LVS before merging → re-simulate post-layout (if performance drops more than 10%, go back) → package into a hardmacro (LEF + Liberty + GDS + Verilog) → co-simulation / hardware verification. The hardmacro has to be done before the digital floorplan, because its LEF abstract is needed to place the mixed-signal top.

Mixed-signal M1–M4: merge the analog hardmacro's GDS into the digital top and place it → check power-domain crossings and whether the level shifters / isolation cells that should be inserted actually are → AMS co-simulation + interface signal integrity → top-level PV for final sign-off.

One abstraction that ties the whole flow together: a transform + a gate

By now there are a lot of steps, but after walking the whole thing once I distilled out the abstraction that helped me most — the one that suddenly made the entire map easy to read:

Every step is, at heart, "one transformation + one checking gate." The transformation has a defined input format and output format; the gate answers "did this step actually succeed" — and the answer has to be true.

With this abstraction, whenever I hit a step I've never seen, I can immediately ask three questions: what format does it eat, what format does it emit, and who decides its "success"? This loops right back to ATLAS's Ratchet and Skill-back: the transformation is usually handed to a tool or to the AI, and the gate — whenever it can be written as a deterministic program — gets locked into the program layer (the ratchet only moves forward); only the ones that genuinely can't be frozen get an AI Skill as a backstop.

Let me add one honest note, and I'll say it only once: this fairly complete table was not planned in one sitting by some experienced architect. It was hammered into shape one cell at a time — every time I found a step that could quietly pass without really being done, I added a checking gate; every gate I added made the map a little more solid. That's exactly why it earns the right to be frozen into a canonical flow: the whole of Phase 1/2/3 is fixed in one YAML as the single source of truth, and a flow_compliance_check.py emits a PASS/FAIL matrix per project — claiming PASS without having run that compliance check is itself a violation.

With the flow built, and "every step has a real checking gate" locked into the foundation, the next move is to verify it — especially the front-most, most AI-dependent step: Spec → RTL. In Part 2, I'll cover how I used a large pile of benchmarks to grind that step to a clean pass, and how the two paths — Program-First and AI-Backup — cross-check each other and converge.