AdvancedQuestion 24 of 63

Why does a clean STA report not guarantee a working chip?

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

Static timing analysis (STA) only checks that data arrives inside the setup and hold windows implied by the constraints you gave it - it cannot tell you whether those constraints describe the real hardware. A report with zero setup and hold violations can still ship a broken chip if a false path hid a real one, a clock-domain crossing was never checked for metastability, or a whole cone of logic was left unconstrained and silently dropped from the count.

A block diagram of a clock-domain crossing synchronizer between clk_ref and clk_usb, with a false path arrow spanning both clocks and a bypass wire added later that the false path still silently covers, next to a PrimeTime report showing 0 violations both before and after the ECO — Technical Reference DiagramWhy does a clean STA report not guarantee a working chip?

Technical Reference DiagramWhy does a clean STA report not guarantee a working chip?

Technical Explanation

STA checks compliance, not truth. It reports whether data meets the setup and hold requirement for every path it was told to check - not whether it was told about every path that matters.
An exception can remove a real path from consideration. A set_false_path (SDC) written too broadly can mark a path as never-toggling when it actually does; that path disappears from the report entirely, and nothing in the "0 violations" summary flags it.
An unconstrained endpoint is invisible in the pass/fail count. If a register's data pin has no set_input_delay (SDC) or its clock pin was never reached by a create_clock (SDC), PrimeTime drops that path from the setup/hold tally. The check_timing (PT) command surfaces this - but only if someone runs it and reads the warnings.
Clock-domain crossings are a different failure mode than timing. STA times paths inside a clock relationship; a synchronizer between two asynchronous clocks is usually marked with set_false_path or set_clock_groups -asynchronous (SDC) precisely because STA cannot judge metastability risk - a separate CDC-checking tool is needed for that.
Dynamic effects sit outside the static model. IR drop and voltage droop change delay in ways that only show up under real switching activity; STA only sees them if you explicitly folded a margin for them into your derates.
A clean report is a necessary condition, not a sufficient one. It confirms the constraints you wrote are satisfied - it says nothing about constraints you forgot to write.

Common Mistake

Treating a "0 setup violations / 0 hold violations" summary line as proof the design works, without checking how many paths were excluded by exceptions or left unconstrained.
The failure is invisible in the report itself: an over-broad false path or a missing clock definition doesn't produce a violation, it produces silence.
Cost: a functional bug or a metastability failure ships to silicon because the "clean" report never looked at the path that actually mattered.

Follow-up Question & Model Response

If two designs both report zero setup and hold violations, what would you check before trusting either one for tapeout?

Candidate Model Response: I would run check_timing (PT) and read every warning, not just the summary, because it lists unconstrained endpoints, clocks with no source, and ignored exceptions that a plain violation count hides. I would also run report_exceptions -ignored (PT) to see which false-path and multicycle commands were silently overridden by something broader. Beyond that, I would confirm that every clock-domain crossing has a CDC-specific check, not just a false path, since STA is not built to catch metastability. A clean STA report only means the paths it actually evaluated are fine - the real question is how many paths it never evaluated at all.

Practical Example

A USB block bridges a 100MHz clk_ref domain to a 60MHz clk_usb domain through a 2-flop synchronizer. An early SDC wrote set_false_path -from [get_clocks clk_ref] -to [get_clocks clk_usb] (SDC) to exclude the synchronizer's first flop from setup/hold checking, since its input is inherently asynchronous. A later ECO added a direct combinational tap from a clk_ref register straight into clk_usb logic, bypassing the synchronizer entirely - but the clock-level false path still matched it, because it was written between clocks, not between the specific synchronizer pins. PrimeTime reported the same 0 violations before and after the ECO. The chip passed signoff and failed intermittently in the field until the bypass path was traced with a CDC tool that the false path had never been asked to check.

Complete STA Handbook