SDC Constraints Interview Prep
SDC constraints for interviews: create_clock and create_generated_clock, set_input_delay/set_output_delay, false paths vs asynchronous CDC, multicycle paths, and how SDC drives STA signoff.
Quick answer
SDC (Synopsys Design Constraints) is the Tcl-based industry-standard format for expressing a design's timing intent to every tool in the implementation flow: synthesis, place-and-route, and static timing analysis (see /topics/static-timing-analysis-sta).
Interviewers ask about SDC because it is the layer where a candidate's design-level understanding of a chip has to become a precise, machine-checkable statement — and getting it wrong either hides real bugs (an unjustified false path or multicycle exception silencing a genuine timing violation) or wastes enormous engineering effort chasing artificial failures (a missing generated-clock relationship or a missing asynchronous clock-group declaration making STA report violations on paths that were never actually timing-critical).
Editorial review
Written by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Reviewed by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Last reviewed
Editorial review pending
Built from curated topic maps, editorial validation, and subject-matter review so the page stays aligned with the interview intent and the current content pipeline.
Key points
- SDC is the timing-intent contract read by synthesis, place-and-route, and STA — without it, STA has no clock period, no I/O timing budget, and no way to exempt paths that are never functionally sensitized.
- create_clock defines a real clock (period, waveform/duty-cycle); create_generated_clock describes a clock derived from another clock (a divider, a PLL output) so its period and phase propagate correctly.
- set_input_delay / set_output_delay model the real external timing budget at chip boundaries — they should reflect the actual driving/receiving device, not be arbitrary padding.
- A false path is a structurally real path that is never functionally exercised; an asynchronous clock-domain crossing is NOT automatically a false path — it needs set_clock_groups -asynchronous, a CDC synchronizer, or a bounded set_max_delay.
- Multicycle paths must be functionally justified (a real N-cycle enable), not used to quiet a timing report — an unjustified exception masks a genuine violation instead of removing a false one.
What it is
SDC (Synopsys Design Constraints) is the Tcl-based industry-standard format for expressing a design's timing intent to every tool in the implementation flow: synthesis, place-and-route, and static timing analysis (see /topics/static-timing-analysis-sta). It is the layer where a designer tells the tools facts about the design that cannot be derived from the netlist alone — what clocks exist and at what frequency, how external data lines up with those clocks at chip boundaries, and which structural paths in the netlist are never actually exercised or are deliberately allowed more than one cycle. The core constraint categories are clocks (create_clock for real clocks, create_generated_clock for clocks derived from another clock such as a divider or PLL output), I/O timing (set_input_delay and set_output_delay, which model the real external devices at chip boundaries), and exceptions (set_false_path for structurally real but never-sensitized paths, set_multicycle_path for paths functionally guaranteed more than one cycle, and set_clock_groups for defining or explicitly declaring the relationship — including "no defined relationship" — between clock domains). Every downstream tool reads the same SDC, so an inaccurate or incomplete constraint set propagates wrong assumptions through synthesis, physical design, and signoff simultaneously, which is why SDC accuracy is treated as a first-class deliverable, not an afterthought written once and never reviewed.
Why interviewers ask
Interviewers ask about SDC because it is the layer where a candidate's design-level understanding of a chip has to become a precise, machine-checkable statement — and getting it wrong either hides real bugs (an unjustified false path or multicycle exception silencing a genuine timing violation) or wastes enormous engineering effort chasing artificial failures (a missing generated-clock relationship or a missing asynchronous clock-group declaration making STA report violations on paths that were never actually timing-critical). A candidate who can write correct, minimal SDC for a small multi-clock block is demonstrating that they understand both the design's real timing behavior and how the tools interpret constraints literally rather than intelligently. The false-path-versus-asynchronous-CDC distinction is one of the sharpest discriminators in this topic, because it is a common and consequential misconception: declaring an asynchronous crossing as a false path suppresses checks on the synchronizer itself, which is exactly the structure that needs to be verified. Interviewers also probe multicycle-path discipline because over-using exceptions to make a timing report look clean is a realistic and dangerous shortcut under schedule pressure, and distinguishing candidates who understand this from candidates who see SDC purely as a tool to silence red numbers is high-value signal for any implementation-adjacent role.
Common mistakes
The most common mistake is treating an asynchronous clock-domain crossing as a false path. It is a real, functionally exercised path with a genuinely undefined timing relationship between clocks — the correct declaration is set_clock_groups -asynchronous (or a bounded set_max_delay, or reliance on a verified CDC synchronizer), never set_false_path, because a false path suppresses even the legitimate structural checks the synchronizer itself needs. The second mistake is forgetting create_generated_clock for internally derived clocks (a clock divider, a gated clock, a PLL output modeled pre-RTL) and instead either leaving the derived clock undefined or defining it as an independent create_clock with no declared relationship to its source — both approaches make STA analyze the derived clock incorrectly relative to its parent. The third mistake is setting I/O delays as arbitrary round numbers instead of modeling the real external device's timing — an input delay set too optimistically hides a real board-level timing problem, and one set with the wrong sign or -max/-min pairing can mask a genuine hold violation at the chip boundary. The fourth mistake is over-using set_false_path or set_multicycle_path to make a timing report pass without functional justification — an exception must correspond to something actually true about the design's behavior (a path genuinely never sensitized, an enable that genuinely only fires every N cycles), or it silently converts a real bug into a passing signoff report. The fifth mistake is writing SDC once early in the project and never revisiting it as RTL changes — a newly added clock, a newly added asynchronous interface, or a removed configuration-only path all require SDC updates, and stale constraints are a common source of late-stage timing surprises that show up only at final signoff.
Core SDC constraint types and what each tells the timing tools
| Constraint | What it declares | Interview trap |
|---|---|---|
| create_clock | A real clock: period, waveform/duty cycle, the port or pin it applies to | Forgetting a clock that exists only inside the design (not at a top-level port) |
| create_generated_clock | A clock derived from another clock (divider, gated clock, PLL output) with its source and multiply/divide factor | Defining a derived clock as an independent create_clock instead, breaking the phase relationship to its source |
| set_input_delay / set_output_delay | The real external timing budget at a chip boundary, modeling the driving or receiving device | Using arbitrary padding instead of the real external device timing; wrong -max/-min pairing hides a hold problem |
| set_false_path | A structurally real path that is never functionally sensitized | Applying it to an asynchronous clock-domain crossing, which is real and needs set_clock_groups -asynchronous instead |
| set_multicycle_path | A path functionally guaranteed more than one clock cycle to propagate | Using it without functional justification, masking a genuine single-cycle violation |
Frequently asked questions
- What is SDC, and how does it relate to static timing analysis?
- SDC (Synopsys Design Constraints) is the industry-standard Tcl-based format for describing a design's timing intent to synthesis, place-and-route, and static timing analysis (STA) tools: what clocks exist and at what period, when I/O data is valid relative to those clocks, and which structural paths should be exempted from normal timing checks. STA (see /topics/static-timing-analysis-sta) does not know what you intend a design to do -- it only knows what the netlist and the SDC tell it. Without an accurate create_clock, STA has no clock period to check setup/hold against; without accurate I/O delays, it cannot compute the true arrival/required time at chip boundaries; without correct exceptions, it will report failures on paths that can never actually be sensitized. SDC is therefore the contract between what the designer knows about the design's real behavior and what the timing tools can independently verify.
- What does create_clock actually specify, and what is the difference between a defined clock and a generated clock?
- create_clock -period 2.0 -waveform {0 1.0} [get_ports clk] defines a clock: its period, its rising/falling edge times within that period (the waveform, which lets you model duty cycle and clock inversion), and the object it is applied to (usually a port or a pin). Every clock referenced anywhere in the design -- including clocks generated internally by dividing, multiplying, or gating an input clock -- needs to be described to the tool. A create_generated_clock command describes a clock derived from another clock (a divide-by-2 output, a PLL output modeled before RTL owns the actual PLL primitive) in terms of its source and a multiply/divide factor, so the tool can propagate the correct derived period and phase relationship rather than treating the generated clock as an unrelated, independently-defined clock -- which would produce incorrect (usually overly pessimistic or silently wrong) timing analysis at the clock-domain boundary.
- What do set_input_delay and set_output_delay actually mean, and what is a common mistake with them?
- set_input_delay -clock clk -max 1.5 [get_ports data_in] tells the tool how long, relative to the reference clock edge at the chip pin, external data takes to become valid at the input port -- effectively modeling the driving device's clock-to-output plus board delay so STA can compute a correct arrival time at the first internal register, exactly as if that external device were another synchronous stage. set_output_delay does the mirror image at an output port: how much setup time the downstream receiving device needs after this chip's output changes. The common mistake is treating these as arbitrary padding numbers instead of modeling the real external timing budget -- an input delay set too small makes internal timing look artificially comfortable while the actual board-level path is tight, and a delay set with the wrong -max/-min pairing can hide a genuine hold problem at the boundary. A correct constraint reflects the real external device's data sheet or interface spec, not a guess.
- What is a false path, and how is it different from an asynchronous clock-domain crossing?
- A false path (set_false_path) tells STA that a structural path in the netlist is never functionally sensitized, so timing it produces meaningless results that would otherwise show up as violations with no real consequence -- classic examples are a configuration register written once at boot and never touched again during normal operation, a mutually-exclusive mux select path, or a scan/test-only path. A common misconception is that a crossing between two unrelated (asynchronous) clock domains is automatically a false path -- it is not. An asynchronous crossing is a real, functionally exercised path whose timing relationship genuinely does not exist between the two clocks; it needs to be declared with set_clock_groups -asynchronous (so STA stops trying to time a relationship that has no defined phase), or protected with a proper CDC synchronizer, or bounded with set_max_delay -- never dismissed with set_false_path, because that would suppress even legitimate structural checks like the synchronizer's own internal timing.
- What is a multicycle path, and what is the risk of over-using it?
- A multicycle path (set_multicycle_path) declares that a specific path is allowed more than one clock cycle to propagate -- for example, a slow arithmetic datapath whose result is only sampled every N cycles by a downstream enable, or a path deliberately designed to take two cycles because it cannot close in one. Declaring it correctly tells STA to check setup against N cycles instead of one, avoiding a false failure report and avoiding wasted synthesis/placement effort trying to squeeze a two-cycle-by-design path into one cycle's worth of logic. The real risk is over-using multicycle exceptions to make a red timing report turn green: if the path is not actually functionally guaranteed to have N cycles (the enable logic that is supposed to gate it every N cycles has a bug, or a corner case samples it early), the multicycle declaration masks a genuine violation instead of eliminating a false one. Every SDC exception -- false path or multicycle -- needs a functional justification, not just a timing-report justification.
- How does SDC relate to what the RTL and physical-design teams actually do?
- SDC is the shared contract across the whole implementation flow: RTL design (see /topics/rtl-design) implies which paths are structurally real and which are functionally exempt (informing false-path and multicycle declarations); synthesis reads clock and I/O constraints to optimize the netlist toward the intended frequency; physical design (see /topics/physical-design-backend-flow) uses the same clock definitions to build the clock tree and uses I/O delays to budget pad-to-core timing; and STA signs off the whole implementation against the same SDC at every corner. An SDC bug -- a missing generated-clock relationship, an overly aggressive false path, an I/O delay that does not match the real board -- propagates incorrect assumptions through every downstream tool, which is why SDC review is a standard, dedicated step in tapeout signoff rather than something left to whichever engineer happens to write the first constraint file.
- How should I practice SDC for an interview?
- Take a small block with two clocks (a fast core clock and a slower peripheral clock generated by dividing the core clock) plus one external input synchronized to the core clock and one output driving an off-chip device. Write the full constraint set by hand: create_clock for the core clock, create_generated_clock for the divided peripheral clock, set_input_delay and set_output_delay for the boundary signals, set_clock_groups -asynchronous if the two clocks are genuinely unrelated (or the correct generated-clock relationship if they are related), and a set_false_path for a configuration register written once at reset. Then narrate, for each constraint, what would go wrong in STA if you omitted it -- that narration is exactly the signal interviewers are listening for, more than syntax recall.
Related topics
Essential AI-Native Skills for SDC Constraints
Modern engineering work increasingly uses AI tools for design and code review, debugging, documentation, test and testbench generation, and workflow automation. The goal is not to let AI replace engineering judgment — it is to move faster while keeping verification discipline.
- Use AI to explain unfamiliar code, logs, waveforms, datasheets, or test failures.
- Break large problems into small, reviewable steps you can verify independently.
- Ask AI for hypotheses, then validate them against tests, measurements, simulations, or lab data.
- Version-control your analysis scripts, testbenches, and configs — keep changes small and reviewable.
- Document your assumptions, design tradeoffs, and debugging decisions.
- Verify AI output before trusting it: run the checks that fit the domain — unit tests, linters, simulations, or bench/lab measurements.
- Review AI output for correctness, edge cases, and real-world consequences.
SDC Constraints — coming to the question bank
The adaptive practice engine is already live for core wireless, RF, and ML systems. SDC Constraints isn't covered in the question bank yet — get notified when it's added.