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

How do you read a clock skew report from report_clock_timing?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

Short Answer

Clock skew is the difference in arrival time of the same clock edge at two different flip-flops, and it can help or hurt a setup or hold check depending on its sign. report_clock_timing -type skew (PT) lists, for a chosen clock, the launch and capture arrival times at the worst pair of registers and the skew between them, so you can see whether the clock network itself is adding or removing margin on a path.

Technical Reference DiagramHow do you read a clock skew report from report_clock_timing?
Timing diagram of a clock tree with two flops FF_A and FF_B, showing 85ps of skew between their clock arrival edges and how that skew adds to setup slack but subtracts from hold slack.

Technical Explanation

  • Skew comes from unequal insertion delay in the clock tree, different wire length, buffer count, or load between the clock source and each flop.
  • report_clock_timing -type skew -clock CLK1 (PT) reports the worst-case skew for that clock, naming the launch and capture pins involved.
  • Positive skew, where the clock arrives later at the capture flop than the launch flop, effectively gives a setup check extra time, because the capture edge is delayed.
  • The same positive skew takes time away from the hold check, because the capture edge moves later while the data launched earlier is still expected to hold.
  • A report showing near-zero skew across most of the design but a large value at one pair of flops usually points to an unbalanced clock tree branch, not a data-path problem.
  • Skew is reported separately from clock uncertainty, which is a margin the designer adds on top for jitter and modeling error, not the actual insertion-delay difference.
  • Reading the skew report before chasing a marginal setup or hold violation shows whether the clock tree or the data path is the real lever to pull.

Common Mistake

The Trap: Assuming skew is always bad and trying to reduce it everywhere, even on paths where the existing skew is protecting a marginal setup check.

  • Cutting skew (rebalancing the clock tree) on those paths can turn a passing setup check into a hold violation instead, so skew needs to be read per path, not minimized blindly.

Follow-up Question & Model Response

Why can the same clock tree show acceptable skew on the setup check and still fail hold at the exact same pair of flops?

Candidate Model Response: Setup and hold checks use the skew in opposite directions, since setup benefits from the capture clock arriving late while hold benefits from it arriving early. If the clock tree was tuned to help one check, it works against the other at that same register pair. A design that looks clean because setup margin is generous can still fail hold once the same skew value is applied on the other side of the check. This is why skew is reviewed for both checks, not folded into a single pass/fail number.

Practical Example

On a 500MHz clock domain, report_clock_timing -type skew -clock CORE_CLK (PT) shows 85ps of skew between FF_A (launch) and FF_B (capture), because FF_B sits three buffer stages deeper in the clock tree. The setup check on that path has 40ps of slack partly thanks to this skew, but the paired hold check has only 12ps of slack left, a candidate for the design team to flag before assuming the whole domain is safe.

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. →