How does latch time borrowing affect closure, and why cap it?

Short Answer

When data reaches a transparent latch after its opening edge, the path borrows time and the next stage starts later by the same amount. Closure looks easy on the first stage and the deficit shows up downstream, possibly several stages later. Capping borrowing with set_max_time_borrow (SDC) keeps each stage honest and leaves margin in the pulse width, which you want in signoff.

Technical Explanation

• PrimeTime computes the maximum borrow for each latch from the clock pulse width, adjusted for clock latency difference, clock uncertainty difference, CRPR and the library setup time of the endpoint latch. The adjustments are listed in the Time Borrowing Information section of report_timing (PT).
• Borrowing is a transfer, not a gain. The time borrowed at the endpoint is given to the startpoint of the next segment. If that segment has no slack, it fails, and the report points at a path that did not cause the problem.
• Chains of latches pass borrowing along. By default PrimeTime analyses single-segment paths between latches. Advanced latch analysis, enabled with timing_enable_through_paths (PT) (default false), shows paths through transparent latches as a whole.
• set_max_time_borrow (SDC) limits borrowing at latch endpoints in its scope. PrimeTime then limits borrowing to the specified amount or the default from the adjusted pulse width, whichever is smaller.
• A value of zero makes PrimeTime analyse the latch like a flip-flop. A negative value requires data to be stable before the opening edge, which is useful for enable inputs on clock-gating latches.
• Why cap it: pulse width depends on duty cycle and clock distribution, which vary with corner and silicon. A design that closes by borrowing nearly the whole pulse has no margin for either. A cap also stops optimisation from leaning on borrowing and leaving real work for later stages.
• report_exceptions (PT) shows the max_time_borrow attributes, and remove_max_time_borrow (PT) removes them.

Formula Or Decision Rule

• Max borrow (default) = nominal pulse width + clock latency difference + clock uncertainty difference + CRPR difference − library setup time, as reported in the Time Borrowing Information section.
• Effective limit = min(set_max_time_borrow (SDC) value, default max borrow).
• Time given to next startpoint = actual time borrowed, adjusted for uncertainty and CRPR on the opening edge.
• Rule: limit = 0 means flip-flop-like analysis; limit < 0 means data must settle before the opening edge.

What To Check

• Actual borrow against max borrow on every latch endpoint, per scenario.
• Slack of the next segment after each large borrow.
• Latches borrowing more than the agreed cap, for example half the pulse.
• max_time_borrow attributes actually applied, from report_exceptions.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Worst actual borrow at 40% of max borrow, and every downstream segment positive with the cap applied.
• Suspicious (illustrative): Latches borrowing over 90% of the pulse in the slow corner while their next segment has under 10 ps.
• Hard stop: Timing that closes only with unlimited borrowing, and fails as soon as the agreed cap is applied. The logic has to be rebalanced.

What The Interviewer Is Testing

• Can you explain borrowed time and time given to the next stage?
• Knowing how PrimeTime computes the default maximum borrow.
• Justifying a cap with margin and predictability, not only with rules.

Follow-up Question & Model Response

"How would you find where a borrowing deficit really started?"

Candidate Model Response: I follow the borrow forward. Each latch report shows the actual borrow and the time given to the next startpoint, so I trace from the first latch with a large borrow to the segment that finally fails. Advanced latch analysis can show the whole path through the transparent latches at once. The fix usually belongs where the borrowing started, by speeding up that stage, not where the failure is reported.