ASIC Tapeout Readiness: The Gaps That Hide Between Teams

Every ASIC programme has a readiness meeting, even if nobody calls it that. The tapeout slot is a few weeks away, the foundry date is locked, and someone senior asks whether the team is actually ready. The room goes quiet, because the honest answer is rarely a clean yes. It's usually "yes, but," followed by a handful of small items that nobody quite owns. Each one is survivable alone. Together, they explain why engineering leads lose sleep in the final month.

SignOff Semiconductors has sat in many of these meetings on its own programmes and on customers' programmes. Its engineers see the same items recurring, and they've found that most of them can be kept off the list if they're handled early. Here's my read on the ones that come up most.

Two engineers, one spec, two designs

A lot of silicon bugs aren't really bugs. They're two competent engineers who each built exactly what the specification said, as they understood it. The RTL designer reads a sentence about reset behaviour one way. The verification engineer reads it another way and writes tests that pass against the first interpretation. Everything comes up green, and the mismatch only surfaces on the bench, in one operating mode, months later.

The fix SignOff recommends is unglamorous: put the RTL, verification, DFT and physical design leads into the spec review, not just the architects. Ambiguity tends to cluster in the same few places every time, namely reset, clocking, power modes and failure behaviour. If those are written down explicitly, a lot of late-night debug never happens.

Timing problems that are really constraint problems

When a team is fighting timing in the last month, the instinct is to blame the backend. More often, the real issue is a constraint written months earlier, or never written until synthesis forced the question. A missing false path produces violations that aren't real, and physical design spends days chasing them. An over-broad false path or a wrongly defined generated clock does the opposite and hides violations that are real. An unconstrained test mode can do either.

SignOff's view is that SDC constraints are part of the design. They should be written alongside the RTL and checked with tools, not handed over at netlist time. Timing also needs to be examined across every mode and corner that matters, test modes included, with proper on-chip-variation derates. Finding an unrun corner in week one costs far less than finding it on silicon.

The waiver list nobody has re-read

Every programme has a list of CDC and RDC waivers, each marked "reviewed, safe." Some of them were approved against a version of the design that no longer exists.

Clock-domain crossing bugs are among the nastiest to chase in silicon. They're intermittent, and RTL simulation doesn't model metastability, so a design can pass every test and still fail. Structural CDC analysis catches missing or wrong synchronisers. Protocol and reconvergence issues usually need assertions or formal checks on top. Both only pay off if they run regularly rather than just before signoff, and if someone re-reads the waivers whenever the RTL changes. That's where yesterday's "known safe" quietly turns into today's risk.

Power intent that simulates fine and still won't wake up

Most SoCs now have multiple power domains, and power intent is easy to get subtly wrong. A missing isolation cell, a level shifter in the wrong place or a retention register that doesn't retain can leave functional simulation looking flawless while the chip fails to come out of sleep.

The usual cause is mundane: the UPF file drifted away from the RTL somewhere along the way. Keeping power intent under the same version control as the RTL, running power-aware simulation, and re-checking after synthesis and after place-and-route (when cells get inserted and moved) catches most of these before they cost a respin.

Good die failing on the tester

This one catches people off guard. The design is correct, functional IR drop looks fine, and then a worrying number of parts fail on the tester. The reason is that scan shift and at-speed capture can switch far more of the chip simultaneously than normal operation ever does. That extra current produces IR drop that functional analysis never examined, so good silicon fails for the wrong reasons.

The remedy is to bring DFT into the room from architecture rather than bolting it on after synthesis, and to include test modes in power and IR analysis alongside functional ones. Scan compression, at-speed patterns and memory repair also go more smoothly when they're planned early.

The IP update that arrived last week

Third-party IP saves months on processor cores, memories, SerDes and PHYs. But SignOff's experience is that IP problems rarely originate inside the block. They come from assumptions at the boundary. The timing view and the physical view don't quite agree. The simulation model is one release behind. A hard macro is wired to the wrong power rail.

It's worth confirming that every view (LIB, LEF, abstracts, models) comes from the same release, that the IP has real silicon history on your node and metal stack, and that someone has verified the macro's clocking, reset and power at subsystem level rather than only at the top.

Reports generated from last Tuesday's netlist

This is the one that makes signoff leads wince. The timing report is clean, LVS is clean, and then someone realises both were generated before the last ECO.

Late changes are routine. A bug turns up in the final regression, one more path needs fixing, and the change goes in. The risk isn't the change itself. It's what doesn't get re-run afterwards. After every ECO, functional or timing, equivalence checking, the affected regressions, STA and physical verification all need to run again on the exact database heading to the foundry. Gate-level simulation with real timing is worth adding, because it catches reset, X-propagation and scan-mode problems that RTL simulation often misses.

It reads as obvious on paper. At 11pm three days before tapeout, it's very easy to skip. SignOff ties every signoff report to a specific netlist revision so that a stale report stands out immediately.

One more step worth taking early: leave spare cells and some floorplan room. If a bug shows up in silicon, it can often be fixed with a metal-only ECO that changes a few masks rather than the full set. That's still painful, but far less so than a full respin.

Tapeout isn't the finish line

The GDS goes to the foundry, there's a brief celebration, and everyone exhales. A few months later the silicon arrives and the questions start. Who owns the bring-up board? Are the ATE test programmes ready? Who handles debug if something looks wrong?

The smoothest bring-ups SignOff has seen were planned while the design was still in progress. That meant FPGA prototyping so firmware was ready before silicon, test programmes written before tapeout, and a validation plan covering voltage and temperature rather than room-temperature basics alone. For a new node, an unproven analog block or new IP, a multi-project wafer shuttle or a small test chip first can save considerable pain later.

Why these problems keep recurring

Look at the list and a pattern emerges. Almost none of these problems are hard because the engineering is unknown. Every team knows CDC matters, that UPF needs checking, and that reports should match the netlist. They happen because the work changes hands. The spec goes to RTL, RTL to verification, the netlist to physical design, patterns to the tester, GDS to the foundry, and the die to the package house. Each handoff is a small opening for an assumption to shift without anyone noticing.

When those stages are split across several vendors, the gaps widen. Each party signs off its own piece, and the risk that sits between the pieces belongs to nobody. That's a big reason many teams building their first or second chip prefer a single partner to own the programme from specification to silicon. The appeal isn't that any one stage is special. It's that one team, one set of baselines and one risk register leave fewer places for things to fall through.

SignOff's end-to-end offering

SignOff Semiconductors builds its turnkey ASIC work around that end-to-end model. Its scope runs from architecture and RTL through verification, DFT, physical design and signoff, then tapeout, foundry and OSAT coordination, and silicon validation. The company says its engineers have collectively completed more than 100 tapeouts, with physical design work on processes from 180nm to TSMC 5nm. SignOff also offers to work as an ODC, on a build-operate-transfer basis, or as added engineering capacity for teams that want to keep some stages in-house.

If a tapeout is on the calendar and that readiness meeting is already on your mind, the list above is a reasonable place to start. Pull the waivers, diff the UPF against the RTL, and confirm that every report points at the netlist actually going to the foundry.