AdvancedQuestion 37 of 63Source: Synopsys PrimeTime User Guide: Timing Paths and Exceptions

Why can the same set_false_path command expand differently in PrimeTime than in ICC2?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

When a set_false_path (SDC) or similar exception command names a sequential cell in its -from or -to option, PrimeTime automatically expands that command to every clock or data pin of the cell and applies the exception pin by pin. Some other tools, including IC Compiler II, keep the exception at the cell level instead of expanding it, so the same SDC line can end up resolving overlapping or conflicting exceptions differently depending on which tool reads it.

Technical Reference DiagramWhy can the same set_false_path command expand differently in PrimeTime than in ICC2?
A cell U1 with two clock pins CP1 and CP2 feeding two internal flip-flops; a set_false_path from U1 to U9 shown expanding in PrimeTime into two separate pin-level exceptions, versus a single cell-level box labeled ICC2 that keeps the exception unexpanded around the whole cell

Technical Explanation

  • Naming a cell in -from or -to is shorthand PrimeTime expands automatically. A cell named in -from (SDC) is expanded to every clock input pin of that cell; a cell named in -to is expanded to every data input pin, turning one command into several pin-level exceptions internally.
  • The expanded, pin-by-pin form is visible with the right report. report_exceptions (PT) or write_sdc (PT) shows the exception as it actually applies after expansion, not just the original cell-level command as written.
  • IC Compiler II does not expand the same command the same way. It keeps a cell-level exception scoped to the cell as a whole, rather than breaking it into one exception per pin.
  • This difference only matters when overlapping exceptions interact. Two tools resolving which of several exceptions wins on a shared point can reach different conclusions, if one tool is reasoning about the exception per pin and the other about it per cell.
  • The gap is a documented, vendor-specific behavior difference, not a bug in either tool. Any flow that moves SDC files or exception intent between PrimeTime and ICC2 needs to treat this as a known point where the two tools can disagree.
  • The safest practice is to write exceptions at the pin level yourself, where the distinction matters. Naming the exact pin instead of the cell removes the ambiguity entirely, since there is no expansion step left for either tool to interpret differently.

Common Mistake

  • Assuming a set_false_path -from [get_cells U1] (SDC) command means exactly the same thing, and resolves overlapping exceptions exactly the same way, whether it is read by PrimeTime or by IC Compiler II.
  • PrimeTime silently expands the cell reference to every one of its clock pins; ICC2 keeps it scoped to the cell as a whole, so a second, overlapping exception on one specific pin of that same cell can be treated as redundant by one tool and as a real conflict by the other.
  • Cost: a design that closes cleanly in one tool's timing engine shows a different, unexpected exception-resolution result when the same SDC is handed to the other tool later in the flow.

Follow-up Question & Model Response

If a flow moves a design from PrimeTime-based STA into IC Compiler II for physical implementation, and the SDC has an exception written at the cell level that overlaps a second, pin-level exception, what would you check before trusting that both tools apply the intended exception?

Candidate Model Response: I would run report_exceptions (PT) in PrimeTime first to see the fully expanded, pin-by-pin view of the cell-level exception, and compare that expansion against exactly which pin the second, overlapping exception targets. If the two only overlap on one pin out of several, I would confirm in ICC2's own exception report whether it treats the cell-level exception as covering that pin at all, since it does not perform the same automatic expansion. Where the two tools' views genuinely diverge, I would rewrite the cell-level exception at the pin level explicitly, removing the ambiguity rather than relying on both tools resolving the overlap the same way by coincidence.

Practical Example

An SDC contains set_false_path -from [get_cells U1] -to [get_cells U9] (SDC), where U1 has two clock pins, CP1 and CP2, feeding two independent internal flip-flops. PrimeTime expands this into two separate false-path exceptions, one per clock pin, visible in report_exceptions (PT) as two distinct entries. A second exception, set_multicycle_path -from [get_pins U1/CP2] -to [get_cells U9] 2 (SDC), is later added to relax only the CP2 path. In PrimeTime, this correctly overrides just the CP2 false path while leaving CP1's false path intact, because the expansion made the two pins independently addressable; a tool that kept the original exception scoped to the whole cell U1 would need a different mechanism to achieve the same selective override.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →

Continue practising

Related STA questions

BeginnerWhat is a false path?IntermediateWhat is timing-exception precedence, and why can a broad false path silently swallow an intended multicycle exception?IntermediateWhy should you prefer the -from/-to form of an exception over the -through-plus-clock form?BeginnerWhat does -through, -from, and -to mean when writing a timing exception?