IntermediateQuestion 183 of 192Source: Synopsys PrimeTime User Guide: ECO Flow, TNS-Driven Clock Network Timing ECO

What is TNS-driven fixing, and why allow some endpoints to get worse?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

TNS-driven fixing lets fix_eco_timing (PT) make a clock network change that helps several endpoints even though it makes one worse, as long as total negative slack goes down and WNS stays within a limit. By default no clock change may worsen any violating endpoint, so one shared clock buffer that would fix many paths is rejected. You accept a few worse endpoints because less TNS means less total fixing left, and the WNS cap keeps the trade bounded.

A before and after ledger of four hold endpoints under endpoint targeting, TNS targeting with the default WNS limit, and TNS targeting with an explicit wns_limit, with per-endpoint slack, TNS and WNS for each. — Technical Reference DiagramWhat is TNS-driven fixing, and why allow some endpoints to get worse?

Technical Explanation

The options are -target_violation_type endpoint or tns, plus -wns_limit. Endpoint is the default and the same as leaving the option out: clock network changes may not worsen any endpoint violation.
With tns, clock changes may worsen some violations while fixing others, targeting total negative slack. WNS is held to the existing WNS, or to the value given with -wns_limit.
-wns_limit may be larger or smaller than the existing WNS, and the tool respects it either way. A looser limit gives more room to cut TNS; a tighter one forces WNS to improve.
The PT UG documents this for clock network fixing with -cell_type clock_network, and TNS targeting requires a PrimeTime-ADV license.
Why the clock needs it: a clock buffer shifts arrival for every register below it, so one change moves many paths, some in the good direction and some in the bad. Under the endpoint rule, one path going worse blocks a change that would fix several others.
Endpoints that get worse still need fixing afterwards, usually with a data-path fix local to them. Plan that before you accept the trade.
Compare TNS before and after under the same timing_report_union_tns (PT) setting, which defaults to true, or the comparison means nothing.

What To Check

TNS, WNS and violating endpoint count before and after, under one union TNS setting.
The list of endpoints that got worse, and whether each has a local fix.
Setup slack on paths through the changed clock branch.
Latency and skew on the changed branch.

Command Checks & Actions

PrimeTime (pt_shell)report_global_timing

Records WNS, TNS and violation counts before and after the run.

PrimeTime (pt_shell)

fix_eco_timing -type hold -cell_type clock_network -methods {insert_buffer} -buffer_list {buf1 buf2 buf3} -target_violation_type tns

TNS-driven clock fixing with WNS held to its current value.

PrimeTime (pt_shell)

fix_eco_timing -type hold -cell_type clock_network -methods {insert_buffer} -buffer_list {buf1 buf2 buf3} -target_violation_type tns -wns_limit -0.040

Allows WNS to reach -40 ps in exchange for more TNS reduction.

PrimeTime (pt_shell)report_timing -delay_type min -max_paths 20 -slack_lesser_than 0

Lists the hold paths still failing, including the ones made worse.

Healthy, Suspicious & Hard-stop Results

Healthy (illustrative): TNS from -95 ps to -75 ps, WNS unchanged at -35 ps, one worsened endpoint that has a local fix.
Suspicious (illustrative): TNS improves but the number of violating endpoints rises, or the worsened endpoints cluster on one register bank.
Hard stop: WNS beyond the agreed limit, or setup on the changed clock branch goes negative.

Common Mistake

The Trap: Setting -wns_limit very loose, say -100 ps, to get the biggest TNS drop. The tool uses the room and pushes one endpoint deep into violation. That endpoint then needs a chain of hold buffers that may not fit, and the ECO has traded many small problems for one hard one.

What The Interviewer Is Testing

Knows the default targeting and what tns changes.
Can explain why clock changes, more than data changes, need this option.
Does the candidate plan the fix for the endpoints made worse?

Follow-up Question & Model Response

"When would you not use TNS-driven fixing?"

Candidate Model Response: Late in signoff, when every endpoint must be clean and each ECO round is expensive, trading one endpoint for others only moves the problem. It is also a poor choice when the endpoint that gets worse has no room for a local fix, for example a path into a hard macro pin or a crowded region. And if the violating paths do not share clock branches, there is nothing to trade, so endpoint targeting does the same job with less risk. It fits best mid-flow on hold or setup clusters that share a clock branch.

Practical Example

Tapeout Scenario: Four hold endpoints fail: A -25, B -35, C -20 and D -15 ps, so TNS is -95 ps and WNS -35 ps (illustrative). A buffer in one clock branch would delay the launch clock of B, C and D and the capture clock of A. Endpoint targeting rejects it because A would worsen. TNS targeting inserts 10 ps: B -25, C -10, D -5 and A -35, so TNS is -75 ps and WNS stays -35 ps. With -wns_limit -0.040 it inserts 15 ps: B -20, C -5, D 0 and A -40, TNS -65 ps. A then gets a local data-path hold fix.

PnR Flow Mentor Guide

Master the Physical Design Implementation Flow

Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.

Explore PnR Flow Mentor Guide →