Does PrimeTime (per the supplied PTUG) provide a command to create or schedule 'useful skew,' or is that a different tool's job — and what does PrimeTime actually give you regarding skew?

Short Answer

PrimeTime does not include a command that creates or schedules useful skew (deliberately unbalancing clock arrival times at different flops to borrow slack from one path and give it to another). That scheduling happens upstream, during clock tree synthesis in the implementation tool. PrimeTime's role is downstream: it analyzes and reports whatever skew already exists in the clock tree, using commands like set_clock_uncertainty and report_clock_timing, rather than commands that build the skew into the tree in the first place.

Technical Explanation

• Useful skew is a physical-design technique: instead of building a perfectly balanced clock tree where every flop's clock arrives at the same time, the clock tree synthesis (CTS) engine deliberately delays the clock at some flops and advances it at others, borrowing setup slack from a path with margin to spare and handing it to a path that is tight.
• Building useful skew requires physically changing clock buffer sizing, insertion delay, or routing in the clock tree — decisions made by the place-and-route or CTS engine, which has control over the physical clock network. PrimeTime, as a signoff timing tool, does not build or modify the clock tree itself.
• What PrimeTime does provide is the analysis half of the loop: report_clock_timing (PT) reports the actual latency and skew values the clock tree currently has, set_clock_uncertainty (SDC) lets a designer model expected skew and jitter margin for a prelayout estimate, and report_timing -derate (PT) shows how derating interacts with whatever real or assumed skew is present.
• Before layout, a designer might use set_clock_uncertainty to reserve margin for skew the CTS tool has not built yet, as a conservative placeholder; after layout, the tool switches to using the propagated (real, extracted) clock network delay instead, and any useful skew CTS actually built shows up directly in that propagated delay, not in a PrimeTime-specific skew command.
• Because PrimeTime only measures, not creates, a useful-skew methodology requires a closed loop: CTS proposes a skew schedule targeting specific critical paths, PrimeTime signs off the resulting timing, and any remaining violations get fed back to CTS or ECO flows for another iteration — PrimeTime cannot originate the schedule on its own.
• fix_eco_timing -cell_type clock_network (PT) can adjust clock-network cells during ECO, which can incidentally change realized skew, but this is a violation-driven repair mechanism scoped to fixing specific reported violations, not a general-purpose useful-skew scheduling command.
• What breaks if this distinction is missed: expecting a PrimeTime command to "schedule" skew wastes time searching PrimeTime's command set for something that lives in the CTS or place-and-route tool instead, and can lead to treating PrimeTime's uncertainty margin (a conservative placeholder) as if it were an actual skew allocation strategy.

Follow-up Question & Model Response

"If a CTS tool has already built useful skew into the clock tree, how would you confirm in PrimeTime that the skew is actually being credited correctly to the paths it was meant to help?"

Candidate Model Response: I would run report_clock_timing (PT) on the specific flops the useful-skew schedule targeted, to confirm the actual propagated clock latency at each one matches what CTS reports it built. I would then run report_timing (PT) on the specific paths the skew was meant to help and confirm the reported slack actually reflects the intended arrival-time shift, rather than being unexpectedly offset by an SDC-level set_clock_uncertainty margin left over from the prelayout stage that no longer needs to be as conservative now that real skew data exists.