When you pass a sequential cell to set_max_delay -from / -to, what happens under the hood?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
PrimeTime expands the cell into pins: -from a cell becomes each of the cell's clock input pins, -to a cell becomes each of its data input pins. You can see the expanded, pin-level exceptions with report_exceptions (PT) or write_sdc (PT).
Technical Explanation
Passing a sequential cell — a flip-flop or latch — to set_max_delay (SDC) is convenient shorthand, but the tool doesn't keep the exception at the cell level; it expands it into pins immediately.
- On the
-fromside: the cell expands to each clock input pin of that cell, because that's the point where a path launched by a sequential element actually begins. - On the
-toside: the cell expands to each data input pin, because that's where a path into a sequential element actually ends. - Multi-bit consequence: one command against a multi-bit register or a cell with several clock pins can silently become several pin-level exceptions at once.
- How to check what you actually got: run
report_exceptions(PT) orwrite_sdc(PT) and read the expanded, pin-level form back rather than assuming the cell-level shorthand did what you expected. - Cross-tool inconsistency to watch for: some place-and-route tools, including IC Compiler II, keep the exception at the cell level instead of expanding it to pins. That means PrimeTime and the implementation tool can resolve two overlapping exceptions on the same path differently — same SDC, same design, different winner — because one tool is reasoning about a cell and the other about pins.
Common Mistake
The Trap: assuming a cell-level exception behaves identically in PrimeTime and in the place-and-route tool because it's written as one line of SDC.
- The designer sees the exception apply cleanly in ICC2 at the cell level and assumes PrimeTime signoff will see the same thing.
- Because PrimeTime silently expanded the same command to individual pins, an overlapping, higher-priority exception on just one of those pins can win in PrimeTime but not in ICC2, producing a signoff mismatch that looks like a tool bug rather than a representation difference.
Follow-up Question & Model Response
If two exceptions from different cell-level commands end up overlapping after pin expansion, how do you find out which one actually wins in PrimeTime?
Candidate Model Response: Run report_exceptions (PT) with its options for showing ignored or overridden exceptions, which lists every pin-level exception the tool derived along with an "Ignored" column explaining why a given one didn't take effect — for example, being overridden by a higher-priority exception type. Reading that report pin by pin is the only reliable way to know the outcome, because the original cell-level SDC line doesn't show the expansion or the precedence result. Comparing that against the equivalent report in the implementation tool is how a cross-tool mismatch gets root-caused rather than guessed at.
Practical Example
A 4-bit register REGB with data pins D[0:3] gets set_max_delay 3.5 -to REGB (SDC). Running report_exceptions -ignored afterward shows four separate max-delay exceptions, one per data pin REGB/D0 through REGB/D3, each carrying the 3.5 (ns) value. On the ICC2 side, the same SDC line is read but IC Compiler II keeps a single cell-level entry for REGB, so a later ICC2-only override targeting REGB/D2 specifically has no PrimeTime-side pin exception to compete against until the pin-level expansion is re-checked.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising