At the end of part 2 the chip was hierarchical: nine hardened blocks, eleven instances and a top level of 529,205 instances that placed in about three hours instead of twenty-five. This post is about the next problem, routing the top level, and the method that solved most of it.
The first route check stopped before it started
Chip v2 had a hand floorplan: the hardened blocks along the edges of an 8.6 mm core, the memories in a row in the middle, and channels between the blocks for the top-level logic. Hierarchy fixed the runtime: repair_design took about 2 hours instead of 22.5. But the top-level cells now sat in narrow channels, and the placer's congestion estimate was worse than in the flat chip.
Then the global-route check stopped at pin access: one memory pin had no legal access point. Four of the eighteen memory LEFs had pins up to 59 µm outside the macro. We fixed them as a new memory library version in G2. The same pin failed again: it sat 0.08 µm above a routing blockage. That needed a second library version. The flat chip never got far enough to find either bug.
2:10Watch on YouTube ↗Watch on Bilibili ↗
Testing a fix without starting over
To test the second fix we didn't re-place the chip. A small test version (v3b) linked the placed design read-only, patched the one memory in memory, and ran only the global-route check: 28 minutes instead of three hours of placement first. In G2 that is just another version, with its own stage directory and README, so the shortcut is on the record like any other run.
The verdict: 1,217,748 overflowing tracks, red everywhere, about 43 times the overflow the largest block routed with.
Four ways out, cheapest first
We wrote down four options:
- A. Change one global-route setting (the layer derate that fixed otbn): a 30-minute test.
- B. A bigger core with wider channels.
- C. Place the blocks' pins from the top level.
- D. Harden more blocks.
We tried the cheapest first. A cut the overflow by a third, to 749,885. B, with a 9.6 mm core, cut it by three quarters, to 176,749. That was still six times what otbn routed with.
But the numbers said something useful. Average track demand was only 22%, yet the horizontal layers overflowed. That pattern means local hot spots, not a chip that is too small. The next question was where they were.
Step 1: measure
A test version (v4a) linked v4's placed design and ran one extra stage, a probe. In 15 seconds and 1.6 GB it wrote out the endpoints of every congested net, every block pin and every cell. Its README says where the overflow comes from, which nets cause it and what to try next.
2:20Watch on YouTube ↗Watch on Bilibili ↗
What it found:
- 87% of the overflow sat over two blocks: otbn (40%) and the Ibex core (39%), and 85% of it was horizontal.
- Over a hard block only one layer runs horizontally (metal 9 in our stack), with one track per routing-grid cell. Any top-level wire crossing a block horizontally competes for that one track.
- The key manager's logic (51,757 cells) was packed into the 400 µm channel between kmac and the Ibex core: 42% of it in that one channel.
- otbn's pins faced away from kmac, so some kmac-to-otbn nets ran over 9 mm.
Step 2: rank candidates with a model, no EDA run
The "level 1" model is a quick what-if script, not an EDA run. It moves the blocks together with their pins, puts each top-level module at the centre of what it connects to, and estimates the wiring. Candidate A put otbn in a corner with kmac next to it, mirrored two large macros and left the centre open. Estimated block-to-block wiring dropped from 9.38 m to 5.59 m, and the number of nets that cross a block dropped from 939 to 47.
Step 3: check the best candidates with short real runs
"Level 2" is real but short: global placement, legalization and a global-route check, about an hour per candidate, each as its own test version.
| Candidate | What changed | GRT overflow |
|---|---|---|
| v4c | old floorplan, same short flow (baseline) | 191,127 |
| A | otbn in the corner next to kmac, centre open | 32,806 |
| A2 | a variation of A | 38,152 |
| A3 | a variation of A | 45,650 |
The two variations taught us something too: a block in the centre blocks traffic, and keeping interface pins close beats giving the logic more room.
Step 4: the full run
Then we placed candidate A for real as chip v5. The prediction held: 34,639 overflowing tracks (−80% from v4), 17% average demand and 22% less wire (103.0 m → 80.1 m).
What was left were two bands, over kmac (59%) and entropy_src (35%), mostly the key manager's bus into kmac. That was about the level the largest block had routed with, so we decided to route it. The model also has limits: it places modules about a millimetre off, which is why the level-2 check is the real test.
The whole method fits in one line: measure, rank, check, then run. Cheap steps first.
Routing the chip: 26 hours, and what the prediction missed
After placement came clock tree synthesis, its repair, routing, post-route and finish. On paper, six stages. In practice it took twenty tries, mostly because of memory. (That story is part 6.)
2:09Watch on YouTube ↗Watch on Bilibili ↗
The detailed route ran 26 hours in 11 passes, from 1,035,993 violations after the first pass to 15,056 after the last. For the first three passes the chip behaved like the blocks. On pass 3 the blocks' violations dropped by 4 to 20 times; the chip's dropped by only 3.2 times. After that, every pass took longer and removed less.
The leftovers are where the global router said they would be. It had found 80% of its overflow over kmac. The detailed router couldn't fit those wires either and pushed them into the channel just south of kmac: 81% of the violations sit in 2.5 mm².
Our prediction had called the chip routable because the overflow was only 0.022% of all tracks. That turned out to be the wrong measure. Two rules came out of it:
- Use the worst small window, not the total. In the worst 0.25 mm² global-route window, the chip had 1,340 overflowing tracks. The blocks that routed had 149 to 238.
- Stop when passes stall. When each detailed-route pass removes less than a fifth of what's left, more passes won't finish the job.
Then a decision: fix the floorplan around kmac, about two more days, or finish now and write the leftovers down. This is a flow demonstration, not a tape-out, so we finished. Post-route and finish completed, and every leftover is in the version's notes. Fixing the kmac channel, checked with the worst-window rule before routing, is the first item for chip v6.
What G2 added
Each step of this was a G2 version with a README: the probe, the four short checks and the read-only test that avoided a re-place. That is what made the method cheap to follow. The data, the decision and the next step stayed next to the run that produced them, and the floorplan choice can be traced back through numbers rather than memory.
Next: the finished chip goes to signoff in a separate tool, and that exposed two bugs in OpenROAD.