IntermediateQuestion 51 of 112Source: Synopsys PrimeTime User Guide: Declaring Asynchronous Clock Groups

What happens if you forget set_clock_groups -asynchronous between two truly unrelated clocks?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

Without that declaration, the tool still tries to time every path it can trace between the two clocks, assuming some worst-case edge alignment even if the clocks are driven by separate, unsynchronized oscillators. That worst-case alignment is often physically impossible, so the design sees a false violation with no real data-path fix, since the actual problem is a missing synchronizer, not a timing constraint.

Technical Reference DiagramWhat happens if you forget set_clock_groups -asynchronous between two truly unrelated clocks?
Two clock waveforms, CLK_USB at 60MHz and CLK_CORE at 800MHz, drifting relative to each other with no fixed alignment, and a crossed-out timing arrow between them labeled by set_clock_groups -asynchronous.

Technical Explanation

By default the tool tries to time every path it can trace between two clocks, even when nothing in the design guarantees a fixed relationship between them.

  • Without a declared relationship, the tool still searches for a worst-case edge alignment. It treats the two clocks as if their periods could line up in every possible way, and reports whichever alignment produces the tightest slack.
  • That worst-case alignment is often physically impossible. Two clocks generated by separate, unsynchronized oscillators drift relative to each other constantly, so the specific tight alignment the tool assumes may never actually occur in real operation.
  • The result is a false, or at least meaningless, timing violation. A designer sees a setup or hold failure between the two clocks and has no way to fix it in the data path, because the underlying assumption the tool made was never true in the first place.
  • set_clock_groups -asynchronous (SDC) tells the tool to stop checking paths between the named groups entirely, removing the report instead of leaving a violation with no real fix.
  • Forgetting the declaration does not just create noise — it can hide real problems too. Engineers who see a wall of known-false violations between async domains often start ignoring all violations in that area of the report, including genuine ones that happen to sit nearby.
  • Why it matters: the fix for a truly asynchronous crossing is not a timing constraint at all — it is a synchronizer circuit, which is a design decision the SDC file cannot substitute for; the constraint's only job is to stop the tool from checking a relationship that does not exist.

Common Mistake

The Trap: trying to fix a false async-crossing violation with a data-path buffer or cell resize, the way you would fix a normal setup failure.

  • Since the assumed worst-case edge alignment never really occurs, no amount of data-path delay adjustment makes the report physically meaningful — the fix only quiets a number that was never measuring something real.
  • Teams that see enough of these false violations sometimes start filtering out whole categories of reports by habit, which risks also hiding a genuine violation between two clocks that actually do need fixing.

Follow-up Question & Model Response

You see a setup violation between CLK_USB and CLK_CORE, two clocks from entirely separate, free-running oscillators. Is a data-path fix appropriate here?

Candidate Model Response: No, that combination is a strong signal the two clocks should be declared asynchronous rather than fixed with a data-path change. Since CLK_USB and CLK_CORE come from separate oscillators with no fixed phase relationship, the tool's worst-case edge alignment for that violation is not something that can actually occur in silicon. I would apply set_clock_groups -asynchronous -group [get_clocks CLK_USB] -group [get_clocks CLK_CORE] (SDC) to remove the check, and separately confirm the RTL uses a proper synchronizer — flip-flop chain or handshake — on any signal that actually crosses between those two domains, since that is the real fix for the crossing, not a constraint.

Practical Example

A design has CLK_USB at 60MHz from a dedicated USB PHY oscillator and CLK_CORE at 800MHz from the main system PLL, with no fixed relationship between them. Before any clock-group declaration, report_timing -from [get_clocks CLK_USB] -to [get_clocks CLK_CORE] (PT) shows a setup violation of -180ps at one specific, rare edge alignment. After the team applies set_clock_groups -asynchronous -group [get_clocks CLK_USB] -group [get_clocks CLK_CORE] (SDC), that report disappears entirely, and the team confirms the actual crossing signal already passes through a two-flop synchronizer in the RTL.

Complete STA Handbook

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

Explore Complete STA Guide →
Timing Constraints (SDC) Handbook — nine chaptersSDC ConstraintsNine chapters on clocks, exceptions, and constraint linting. →

Continue practising

Related STA questions

BeginnerHow do you tell PrimeTime that two clocks are asynchronous with set_clock_groups?IntermediateWhat is the difference between asynchronous, logically_exclusive, and physically_exclusive clock groups?IntermediateWhat is the difference between an intra-clock path and an inter-clock path in STA, and why does the tool treat them differently?BeginnerWhat happens in PrimeTime if you forget to define a clock on a clock port?