What is an SDC file, and what are 'basic timing constraints'?
From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide
Short Answer
An SDC (Synopsys Design Constraints) file is a plain-text script that tells the tool what timing the design is supposed to meet — its clocks, its I/O timing, and any exceptions — before synthesis, place-and-route, or STA can check anything against it.
Technical Explanation
STA cannot judge whether a path is "fast enough" unless someone first states what fast enough means. That statement of intent is the SDC file.
- What SDC actually is: a Tcl script written in a widely supported subset, so the same file loads into synthesis, implementation, and PrimeTime without rewriting it for each tool.
- Clock definitions:
create_clock(SDC) sets a clock's period and edges;create_generated_clock(SDC) defines a clock derived from another one, such as a divider output. - Boundary timing:
set_input_delay(SDC) andset_output_delay(SDC) tell the tool how much delay already exists outside the chip, on the paths into and out of its ports. - Timing exceptions: commands such as
set_false_path(SDC) andset_multicycle_path(SDC) tell the tool to relax or skip the default one-cycle check on specific paths that do not behave like ordinary logic. - Why it must stay simple: because other tools — formal equivalence checkers, gate-level simulators — read the same file and only understand the standard SDC command set, not arbitrary custom Tcl logic.
Common Mistake
The Trap: Writing SDC as if it were a general Tcl program, with loops and custom procedures, because the tool loading it happens to accept Tcl syntax.
- A downstream tool that only parses the standard SDC subset will silently skip or fail on anything outside it.
- A constraint that only works in one tool's SDC reader is a constraint you cannot trust anywhere else in the flow.
Follow-up Question & Model Response
Why would two engineers on the same team get different synthesis results from what looks like the same SDC file?
Candidate Model Response: The most common cause is that the file relies on Tcl variables or object queries, such as get_pins or get_clocks, whose result depends on the design loaded at the time — the same command can resolve to different pins on a slightly different netlist revision. I would check whether the SDC references any object by a name that might not exist yet, and whether any command's result depends on load order. Keeping the constraints in the standard command set, with explicit object names rather than clever queries where possible, is the usual way to make an SDC file behave the same for everyone.
Practical Example
A block-level SDC file of about 40 lines defines one 500 MHz core clock with create_clock -name clk_core -period 2.0, sets 0.3 ns of input delay and 0.4 ns of output delay on the block's boundary ports, and adds two set_false_path exceptions for a static configuration bus. That same file, unmodified, drives synthesis, clock tree synthesis, and the final PrimeTime signoff run for the block.
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