In short
Licensed IP is the one part of a chip program the team does not control, and it is the most common outside reason a tape-out moves. The risk is managed by treating every IP drop as a dated commitment with a named owner on both sides, and by knowing, before the vendor's email arrives, exactly which blocks each drop feeds.
Why IP slips
A modern SoC licenses a large share of its content: interface PHYs, memory controllers, processor cores, security blocks. Each comes from a vendor with its own roadmap, its own PDK dependencies and its own other customers. A vendor's drop moves for reasons that have nothing to do with your program: a foundry PDK update, a bug found by another licensee, a priority call in their own schedule.
On the receiving side, the drop is rarely plug-in. Integration needs the vendor's verification IP, its timing constraints and its test wrapper, and each of those can arrive separately. A drop that is nominally on time can still cost weeks if the pieces around it are not.
Contract for dates, not deliverables
The licence usually describes what is delivered. The program needs when, in what state, and what happens if it moves. Before signing, the program lead should know, for each drop: the date, the maturity expected at that date, which of your blocks it feeds, how many days of slack those blocks have, and who at the vendor owns the date.
That last item matters most. An IP date with a named owner on the vendor's side is a commitment that can be chased, escalated and renegotiated. A date in a licence schedule is a hope.
Know the blast radius before the email arrives
The question that decides a tape-out is not whether an IP drop will move; something always moves. It is how fast the program knows what that movement breaks. A four-week delay on an interface PHY might cost two days on one block and twenty-eight on the fabric that depends on it, and the answer is different for every drop.
That map should exist before the email arrives: for each IP, the blocks that consume it, the slack each has, and the date downstream that is first at risk. With the map, the email is a decision. Without it, the email starts a week of meetings.
The first hour after the vendor moves a date
The moment the message lands, three things need to happen: the delay is traced to the blocks it affects and the date it threatens, the recovery options are compared with what each costs, and the one that holds the date goes to the person who can approve it, with the escalation to the vendor already drafted.
This is one of the things Tymeline does on a chip program. It reads the vendor's email alongside the engineering tools, follows the delay through every consuming block, models the recoveries against the real plan, and has the fix in front of the VP of Engineering within minutes. On approval it re-sequences the work, tells every affected owner, and sends the escalation. Tape-out stays where it was.