AdvancedQuestion 22 of 63

How do you decide between set_driving_cell, set_drive, and set_input_transition for accurate boundary modeling?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Default to set_driving_cell (SDC) whenever a real library cell can represent the external driver, since it uses that cell's actual load-dependent delay model. Fall back to set_drive (SDC) for a driver that has no library-cell equivalent, and use set_input_transition (SDC) when the port's slew is genuinely load-independent, or to match another tool that only supports a fixed transition.

Technical Reference DiagramHow do you decide between set_driving_cell, set_drive, and set_input_transition for accurate boundary modeling?

Technical Explanation

  • The goal is representing the real external driver, not just satisfying the tool. Each of these three constraints models the same thing - what drives a primary input port - at a different level of fidelity, and the right choice depends on what actually drives that port in the real system.
  • set_driving_cell: the default, most accurate option. set_driving_cell (SDC) characterizes the port using an actual library cell's delay model - nonlinear (NLDM) or current-source (CCS) - so the port's transition and delay are computed as functions of the load, and stay correct as that load changes. Since most ports really are driven by ordinary standard cells that a library can represent, and since input slew at the boundary feeds every downstream delay calculation, this is the right choice whenever a representative cell exists.
  • set_drive: the fallback for non-library drivers. set_drive (SDC) is for a driver that cannot be characterized as a library cell - a custom analog block, or third-party IP with no Synopsys library model. It represents the driver as a simple drive resistance; you accept lower accuracy for the driver's real nonlinear behavior in exchange for being able to model it at all.
  • set_input_transition: for load-independent slew, or tool matching. set_input_transition (SDC) is appropriate when the port's transition barely depends on the design's own input load - a large external driver into a large external capacitance, where the chip's comparatively small input load has little effect on slew. It is also the right call when matching another analysis tool that only supports specifying a fixed input transition.
  • The precedence rule that catches people. Among these three drive-modeling commands, the most recently applied one wins - a later command on the same port removes the effect of an earlier one. Layering them, expecting the more accurate one to survive, does not work; only the last one applied is in effect.

Common Mistake

  • Applying set_driving_cell for accuracy and then later, in a different SDC file, applying set_input_transition on the same port for convenience - not realizing the second command silently discards the first, more accurate model.
  • Defaulting to set_drive out of habit because it is simpler to write, on a port that is actually driven by an ordinary standard cell the library already characterizes.
  • Cost: a port modeled with less accuracy than the available data supports, or worse, a port whose intended accurate model was silently overwritten by a later, less accurate command elsewhere in the constraint set.

Follow-up Question & Model Response

Two SDC files are read in sequence, and both constrain the same input port - one with set_driving_cell, one with set_input_transition. Which one is in effect, and how would you confirm it without guessing?

Candidate Model Response: Whichever command was applied last, by read order, is the one in effect - these drive-modeling commands don't merge or stack, so the later command entirely replaces the earlier one's effect on that port, regardless of which is more accurate. To confirm without guessing, I'd run report_port -verbose (PT) on the port after both files are read, which shows the currently active drive model, and cross-check the read order of the two SDC files against the script that sources them. Guessing based on which command "should" be more authoritative would be wrong here, since the tool applies no such judgment - only sequence matters.

Practical Example

A top-level SDC file sets set_driving_cell -lib_cell BUFX4 -library slow_1p0v [get_ports data_in], giving that port an accurate, load-dependent CCS-based transition. A block-level SDC sourced afterward, written for a different reuse context, sets set_input_transition 0.15 [get_ports data_in] on the same port out of convenience. report_port -verbose data_in after both files are read shows the fixed 0.15ns transition in effect, not the BUFX4 model - the accurate driving-cell constraint was silently discarded the moment the second file was sourced.

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 →

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.

See what's inside the bundle
VLSI Physical Design Planning Handbook — fourteen chaptersDesign PlanningFourteen chapters, floorplanning through timing budgets.

Continue practising

Related STA questions

AdvancedExplain the interaction between CCS receiver modeling and max-transition/max-capacitance DRC characterization.IntermediateWhat's the difference between clock source latency and clock network latency, and why model them separately before CTS?IntermediateWhat timing checks must be clean before a design can tape out?AdvancedExplain why "only internal nets are annotated in SDF" and how that shapes your verification.