IntermediateQuestion 99 of 112Source: Synopsys PrimeTime User Guide: Reporting Clock Timing

What does an interclock skew report tell you that a single-clock skew report does not?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

Short Answer

A single-clock skew report only compares arrival times of the same clock at different flops, but many real paths launch from one clock and capture on a different one. report_clock_timing -type interclock_skew (PT) reports the timing relationship between two distinct clock edges at the point a path actually crosses between them, which is the number the setup and hold checks on that crossing actually use.

Technical Reference DiagramWhat does an interclock skew report tell you that a single-clock skew report does not?
Two clock waveforms, a 1GHz core clock and a divided 100MHz peripheral clock, with the 250ps interclock skew offset marked at the specific edge pair a status-register path uses.

Technical Explanation

  • Interclock skew is the offset between the edges of two different clocks that a path uses to launch and capture, for example a core clock and a slower peripheral clock.
  • report_clock_timing -type interclock_skew -from_clock CLK_A -to_clock CLK_B (PT) reports this offset directly instead of asking the designer to subtract two separate single-clock reports by hand.
  • The two clocks may have different periods, different sources, or different propagated latencies, so their offset is not a simple average of each clock's own skew.
  • If the two clocks are truly asynchronous, PrimeTime normally analyzes the crossing under set_clock_groups -asynchronous (SDC) instead of a real skew number, since no fixed timing relationship exists between them.
  • When the two clocks do have a known, related relationship, for example one is a divided version of the other, the interclock skew report shows exactly how much margin or penalty that relationship gives the crossing path.
  • Reading this report before debugging a cross-domain setup or hold failure avoids wrongly blaming the data path for what is really a clock relationship issue.

Common Mistake

The Trap: Subtracting two single-clock skew numbers to estimate the crossing margin instead of asking for the interclock report directly.

  • The two single-clock reports may each be measured against a different reference edge, so a manual subtraction can be off by a full clock period and hide a real violation.

Follow-up Question & Model Response

What happens to the interclock skew report if the two clocks are defined with set_clock_groups -asynchronous instead of being logically related?

Candidate Model Response: Once two clocks are grouped as asynchronous, PrimeTime does not compute a fixed timing relationship between them at all, since by definition there is no dependable edge alignment to report. Any path that crosses between them is excluded from normal setup and hold analysis rather than measured with a skew number. That crossing then needs its own handling, typically a synchronizer checked separately from static timing rather than a timing exception. Running the interclock skew report on such a pair would show no meaningful relationship, which is itself confirmation the domains are correctly grouped as asynchronous.

Practical Example

A chip has a 1GHz core clock and a 100MHz peripheral clock generated from it with create_generated_clock -divide_by 10 (SDC). report_clock_timing -type interclock_skew -from_clock CORE_CLK -to_clock PERIPH_CLK (PT) shows a 250ps offset at the specific edge pair a status-register path uses, which the designer folds into the setup check instead of assuming the crossing behaves like two unrelated clocks.

Complete STA Handbook

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

Static Timing Analysis (STA) Handbook — ten chaptersSTA HandbookTen chapters on setup, hold, OCV, and PrimeTime signoff. →