In short
A supplier delay moves your tape-out when the news reaches the dependent teams too late to re-plan. The fix is to connect the supplier's date to every block that depends on it, so that the hour the delivery moves you know which blocks can absorb it, which one cannot, and what the recovery options cost.
How does a late IP delivery become a missed date?
The vendor tells one engineer, by email. That engineer adjusts their own work. The teams integrating the IP keep working to the old plan, because nothing told them otherwise. One to two weeks later the change surfaces in a review, by which time the options that were cheap on day one are gone.
What should happen the day the email arrives?
Four things, in order:
- Trace: find every block that consumes the delayed IP.
- Separate: most blocks can absorb a delay; usually one cannot. In a typical case three blocks absorb four weeks, and one moves by 28 days.
- Cost the options: re-sequence and run work in parallel, take an alternate IP drop, or remove a feature. Each recovers a different number of days at a different price.
- Decide: put one recommendation in front of the person who owns the date, with the escalation to the vendor already written.
Why can't the program office do this by hand?
It can, slowly. Tracing a dependency across design, verification, physical design and firmware means asking four teams and reconciling four answers. That takes days. The value of the answer falls every day it is late.
How Tymeline handles it
Tymeline reads supplier email alongside the engineering tools, so the moved date is connected to the plan the hour it arrives. It traces the impact, compares the recovery paths, and sends the decision to the owner. A person approves; the date holds.