BeginnerQuestion 54 of 95Source: Constraining Designs for Synthesis and Timing Analysis: SDC Basics

What time unit does an SDC file use, and why does getting it wrong break every constraint?

From PDVerse STA Mentor Guide ยท pdVerse Mentor Guide

Short Answer

SDC commands take plain numbers with no unit attached, and the tool interprets every one of them in whatever time unit the design's own technology library or set_units (SDC) statement declares โ€” nanoseconds is the most common default. Every number in the file only means anything relative to that one setting.

Technical Reference DiagramWhat time unit does an SDC file use, and why does getting it wrong break every constraint?
A Liberty library header showing a time_unit declaration next to an SDC create_clock line with a bare numeric period value

Technical Explanation

A bare number like 10 in an SDC file is meaningless without knowing the unit behind it.

  • Where the unit actually comes from: the tool picks up its time unit from the technology or Liberty (LIB) library the design uses, or from an explicit set_units -time (SDC) statement if one is present in the SDC file.
  • Why SDC numbers carry no unit suffix: commands like create_clock -period 10 (SDC) never write "10ns" โ€” the same 10 could mean 10 nanoseconds in one flow and 10 picoseconds in another, entirely depending on the library's declared unit.
  • One wrong assumption scales the whole file: if a designer assumes nanoseconds while the actual library unit is picoseconds, every period, delay, and uncertainty value in the SDC file is off by a factor of a thousand at once, not just one line.
  • The tool will not always warn you: a design meant to run at 1GHz (a 1ns period) written as -period 1 against a picosecond library becomes a 1ps period โ€” 1000 times faster than intended โ€” and the tool may simply report an enormous number of violations instead of an explicit unit error.
  • Consistency across files matters, not just one file: every SDC file, every constraint script, and the library itself all need to agree on the same time unit, since mixing files written under different unit assumptions reintroduces the same error.

Common Mistake

The Trap: writing a period value based on a remembered convention ("SDC is always in nanoseconds") without checking what this specific library actually uses.

  • A designer new to a project reuses a familiar -period value from a previous, nanosecond-based flow without checking the current library's declared unit.
  • The resulting clock period is off by orders of magnitude, and the flood of setup violations that follows gets mistaken for a design timing problem instead of a units mismatch.

Follow-up Question & Model Response

How would you confirm the actual time unit before writing any SDC for a new project? Candidate Model Response: Check the technology library's declared time unit directly, usually stated near the top of the Liberty (LIB) file as something like time_unit : "1ns", rather than assuming it from habit or from a different project. It also helps to look for an explicit set_units (SDC) statement in the existing constraint files for this design, since that overrides any ambiguity and states the unit the whole flow already agrees on.

Practical Example

A library declares time_unit : "1ps". A designer writes create_clock -period 1000 [get_ports CLK] (SDC), intending a 1ns period, and the tool correctly reads it as 1000 picoseconds โ€” exactly 1ns โ€” matching intent only because the designer checked the library's unit first.

Complete STA Handbook

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

VLSI Physical Design Planning Handbook โ€” fourteen chaptersDesign PlanningFourteen chapters, floorplanning through timing budgets. โ†’