In short
A mid-size SoC takes somewhere between twelve and twenty-four months from specification to samples, and most of the slip happens in two places: verification closing later than the curve promised, and physical design looping on late changes. A schedule that treats either as linear is wrong on the day it is written.
The phases, and what each one actually produces
Durations vary with node, team size and how much is re-used, so treat the ranges below as typical for a mid-size SoC on a mature node, not as a plan. What matters more than the numbers is what each phase has to produce before the next can start honestly.
- Specification and architecture, two to three months: a frozen feature list, a block diagram with owners, the IP make-or-buy decisions, and a first power and area budget.
- RTL design and verification, six to nine months, overlapping: block RTL, testbenches, and a coverage plan with targets per block. This phase ends at RTL freeze, which is a decision, not a date that arrives on its own.
- Physical design, three to five months, overlapping with late verification: floorplan, place and route, clock trees, timing closure at every corner, and the ECO loop with verification.
- Sign-off, four to eight weeks: final timing, power, physical verification, DFT and the tape-out review.
- Fabrication, ten to sixteen weeks at an advanced node, plus packaging and assembly: the one phase the team cannot speed up, which is why the date going in has to be right.
- Bring-up and characterisation, two to four months: silicon on the bench, firmware running, test programs debugged, and the first samples to customers.
Where the time really goes
Two things dominate. The first is verification. Coverage closure is a curve, not a line: the last ten percent takes as long as the first ninety, and the curve flattens weeks before anyone calls the milestone late. Teams that watch the slope see trouble a month early; teams that watch the milestone see it the day it is missed.
The second is the ECO loop. A change that reaches physical design late forces a loop through timing, verification and physical verification, and each loop costs weeks. A schedule that allows for zero loops is a hope. The honest plan allows for a known number and holds scope so that the number does not grow.
Behind both sits a third cause that is easy to miss because it is nobody's milestone: a supplier's IP drop, a foundry PDK update, or a package decision that moves and takes the dependent blocks with it.
Why the plan is wrong the day it is written
Most ASIC schedules are built as if the work were software: linear progress, cheap reversals, unlimited iteration. Silicon has none of those properties. Progress is front-loaded until it is not, a reversal after physical design starts costs a loop, and the iteration budget is set by the mask cost.
The fix is not a more pessimistic plan. It is a plan whose assumptions are visible: the coverage rate it needs, the number of ECO loops it allows, the IP dates it depends on. Then the plan can be checked against reality every week instead of every review.
Holding the date you committed to
A schedule holds when the drift is seen while it is small and the fix is made before the date moves. In practice that means reading the coverage curves, the timing reports and the supplier mail every day, tracing what a change breaks downstream, and putting the recovery in front of the person who can approve it that week.
That is what Tymeline does for a chip program: it holds every commitment to the tape-out date, works out the fix when one of them drifts, and gets it approved and carried out before the slip reaches the fab.