Two quiet errors cause large wrong numbers: reading a constraint in the wrong unit, and analysing with the wrong corner. Both look like normal constraints and produce plausible-looking reports. Making units and conditions explicit, and checking them, is cheap insurance.
Item | Where it comes from | Typical mistake |
|---|---|---|
Time unit | Library header | Constraints written in ns while the library is in ps |
Capacitance unit | Library header | set_load in pF versus fF |
Operating condition (process, voltage, temperature) | Library selection per view | Slow library with fast parasitics in a view meant to be consistent |
Parasitic corner | Extraction selection per view | Using the typical extraction for a worst-case view |
# Unit scale errors: the same number in two units
period_in_file = 2.0
assert period_in_file * 1.0 == 2.0 # ns library: 2 ns
as_ps_library = period_in_file * 1.0 # ps library: 2 ps
ratio = 2000.0 / as_ps_library # what was meant (2000 ps) vs what was read (2 ps)
assert ratio == 1000.0
load_pF, load_fF = 0.05, 50.0
assert abs(load_pF * 1000 - load_fF) < 1e-9
print("PASS: a ps/ns mix-up is a 1000x error; 0.05 pF = 50 fF")A period written as 2.0 in a library that works in picoseconds is a 2 ps clock, a thousand times faster than meant: every path fails by a huge margin and the error is obvious. The dangerous case is a smaller mismatch, such as a load 1000 times too small that still looks plausible and is quietly wrong.
The report header (units, library, corner) is part of every review; two reports are compared only when headers match.
Each view defines library corner and parasitic corner together and consistently.
Constraint files declare their units in a comment or by a unit command, and the CI check compares them to the library.
Probably a units mismatch: the period appears to be 2 ps (0.002 ns) while delays are in ns. Check the time unit of the library and of each constraint.