# Timing Closure Is Not Just Fixing Negative Slack

In ASIC physical design, it is easy to reduce timing closure to a simple objective:

**Make the slack positive.**

That is necessary, but it is not sufficient.

A design can show improved Worst Negative Slack and still have serious timing problems. Another design can have a relatively small WNS while thousands of paths remain in violation. A timing report can also point toward one apparent problem while the real cause is somewhere else: the clock definition, an incorrect exception, excessive fanout, congestion, poor placement, clock skew, parasitic effects, or even an architectural decision made much earlier in the design flow.

Real timing closure is therefore not simply an exercise in eliminating negative numbers.

It is a process of understanding **why timing is failing, determining which violations matter, identifying their common causes, and choosing fixes that improve the design without creating larger problems somewhere else.**

That is where engineering judgment becomes important.

## Understanding Slack

At the most basic level, static timing analysis compares when data is required to arrive with when it actually arrives.

For a setup check:

**Setup Slack = Required Arrival Time − Data Arrival Time**

A positive value means the path meets setup timing.

A negative value means the data arrives too late.

For hold timing, the relationship is reversed conceptually: the data must not arrive too early relative to the capture requirement.

The important point is that slack is an **outcome**.

Slack tells us that something is wrong.

It does not necessarily tell us **why** it is wrong.

That distinction is fundamental to timing closure.

## WNS: Worst Negative Slack

Worst Negative Slack, or WNS, is the most negative slack among the paths being analyzed.

For example:

* Path A: −220 ps
* Path B: −75 ps
* Path C: −18 ps

The WNS is:

**−220 ps**

WNS is useful because it immediately identifies the worst failing timing path in a particular analysis scenario.

But it tells only part of the story.

Suppose an engineer optimizes the −220 ps path and improves it to −40 ps. WNS has improved dramatically.

However, there might still be 10,000 other failing paths.

Looking only at WNS could therefore create the impression that the design is approaching closure when the broader timing picture has barely changed.

## TNS: Total Negative Slack

Total Negative Slack, or TNS, adds the negative slack of all failing timing endpoints.

Consider these three violations:

* −100 ps
* −80 ps
* −20 ps

The TNS is:

**−200 ps**

TNS gives us information that WNS cannot provide.

It tells us something about the **breadth of the timing problem**.

Consider two designs.

### Design A

WNS = −300 ps
TNS = −350 ps

This may indicate that timing failure is dominated by a relatively small number of very bad paths.

### Design B

WNS = −80 ps
TNS = −25 ns

The worst individual violation is much smaller, but the design may contain hundreds or thousands of failing endpoints.

These two designs require different strategies.

Design A may require focused investigation of several critical paths.

Design B may indicate a more systemic problem involving placement, congestion, clocking, constraints, buffering, cell selection, or physical architecture.

This is why experienced timing engineers look at **both WNS and TNS**.

Neither number should be used in isolation.

## Violating Path Count Matters Too

A third useful metric is the number of violating endpoints or paths.

For example:

WNS = −50 ps
TNS = −5 ns
Violating endpoints = 3,200

That tells a very different story from:

WNS = −50 ps
TNS = −60 ps
Violating endpoints = 2

The first case suggests a widespread timing problem.

The second may represent a localized issue.

The engineer therefore needs to consider at least:

* WNS
* TNS
* Number of violating endpoints
* Distribution of violations
* Path groups
* Timing corners
* Operating modes

Together, these provide a much more accurate picture of timing health.

## Path Groups Are Essential

Timing paths should not be treated as one giant collection.

Most ASIC designs contain several fundamentally different path categories.

Typical examples include:

* Register-to-register
* Input-to-register
* Register-to-output
* Input-to-output
* Macro-to-register
* Register-to-macro
* Macro-to-macro
* Clock-gating paths
* Recovery and removal paths

There can also be different clock domains and different functional modes.

A design may therefore have excellent timing in one path group and serious problems in another.

For example:

| Path Group |     WNS |     TNS |
| ---------- | ------: | ------: |
| REG2REG    |  −20 ps | −300 ps |
| IN2REG     | −420 ps |   −8 ns |
| REG2OUT    |  +35 ps |       0 |
| MACRO2REG  | −180 ps |   −2 ns |

If the engineer looks only at the global WNS, the dominant input timing problem may obscure what is happening in the internal logic.

Breaking the timing results into meaningful path groups makes the problem much easier to understand.

It also helps determine whether the failure comes from the physical implementation or from the timing constraints themselves.

## Timing Closure Starts With Root-Cause Analysis

A common mistake is to immediately begin resizing cells, inserting buffers, or performing ECO optimization when timing fails.

Before changing the design, I prefer to ask:

**Why is this path failing?**

The answer may have very little to do with the logic cell currently showing up in the timing report.

A timing violation may be caused by:

* Excessive combinational logic depth
* Long routing distance
* High fanout
* Poor placement
* Congestion
* Weak driver strength
* Slow cell threshold selection
* Large capacitive load
* Clock latency
* Clock skew
* Clock uncertainty
* Crosstalk
* Parasitic RC
* Macro placement
* Incorrect clock relationships
* Incorrect generated clocks
* Incorrect false-path definitions
* Incorrect multicycle paths
* I/O delay problems
* Mode or corner configuration errors

Treating every timing violation as a cell-sizing problem is therefore dangerous.

The timing report shows where the symptom appears.

Engineering analysis determines the actual cause.

## Start by Examining the Path

When investigating a critical timing path, I normally want to understand the complete path structure.

That includes:

**Launch point**

Where is the data originating?

**Capture point**

Where is it being captured?

**Launch clock**

Which clock launches the data?

**Capture clock**

Which clock captures the data?

**Clock relationship**

Are the two clocks truly synchronous?

**Logic depth**

How many levels of combinational logic are involved?

**Cell delay**

Are one or two cells dominating the path?

**Net delay**

Is routing contributing most of the delay?

**Fanout**

Is a high-fanout net creating excessive capacitance?

**Physical distance**

Are the launch and capture regions too far apart?

**Congestion**

Is routing detouring around blocked or congested areas?

These questions quickly begin to separate a local timing problem from a structural one.

## Cell Delay Versus Net Delay

One of the most important observations in advanced-node physical design is the relationship between cell delay and interconnect delay.

If the path is dominated by **cell delay**, possible solutions may include:

* Upsizing cells
* Using faster threshold-voltage cells
* Restructuring logic
* Reducing fanout
* Buffering
* Logic optimization

If the path is dominated by **net delay**, blindly increasing cell size may not solve the real problem.

The path may instead require:

* Better placement
* Shorter routing distance
* Buffer insertion
* Congestion reduction
* Macro repositioning
* Layer promotion
* Route optimization

At advanced process nodes, interconnect behavior becomes increasingly important.

The timing engineer therefore needs to understand the physical path, not just the logical path.

## Timing Closure Is Also a Floorplanning Problem

Some timing problems cannot be repaired efficiently at the end of the flow.

Suppose two macros communicate heavily but are placed far apart.

The resulting paths may require:

* Large buffers
* Higher drive-strength cells
* Faster Vt cells
* Aggressive routing
* Additional power

An optimizer may eventually force the path to meet timing.

But that does not necessarily mean it was a good design.

A better solution may have been to place the macros closer together during floorplanning.

This is why timing closure begins much earlier than final-route optimization.

Good timing starts with:

* Architecture
* Floorplanning
* Macro placement
* Pin placement
* Power planning
* Clock planning
* Placement strategy

By the time a design reaches signoff STA, many of the fundamental timing characteristics have already been determined.

## Clock Timing Cannot Be Ignored

Data-path optimization receives much of the attention during timing closure, but clock behavior can be equally important.

A timing violation may change dramatically depending on:

* Clock latency
* Clock insertion delay
* Clock skew
* Clock uncertainty
* Jitter
* Clock reconvergence
* Generated-clock definitions

For setup timing, certain forms of skew may help one path while hurting another.

For hold timing, the situation may reverse.

A clock-tree change that improves setup timing can therefore create new hold violations.

This is one reason timing closure must be approached as a system rather than as a collection of isolated paths.

## Setup and Hold Are Connected

A common setup fix is to make the data path faster.

That can involve:

* Upsizing a cell
* Replacing a high-Vt cell with a faster cell
* Buffering
* Shortening routing
* Restructuring logic

But making a path faster can reduce hold margin.

Likewise, adding delay to repair a hold violation can reduce setup margin.

The correct question is therefore not:

**Did the ECO fix the violation?**

The correct question is:

**What did the ECO do to the entire timing environment?**

Every meaningful timing change should be evaluated against both setup and hold.

## MMMC Makes Timing Closure More Complex

Modern ASIC timing closure is performed across multiple modes and multiple corners.

A path that is critical in one scenario may not be critical in another.

The same optimization may:

* Improve setup in one corner
* Degrade hold in another corner
* Increase leakage
* Increase dynamic power
* Increase congestion
* Increase transition violations

This is why optimizing a single timing report is not sufficient.

The design must converge across the scenarios that matter for signoff.

As scenario counts increase, the engineer needs to identify patterns rather than manually chasing every reported path independently.

For example, if the same physical region repeatedly appears in violations across several corners, the root cause may be physical.

If the violations occur only in one mode, the problem may be related to constraints or mode-specific logic.

That pattern recognition is an important part of timing engineering.

## Do Not Ignore Constraints

One of the most expensive mistakes in physical design is optimizing a path that should never have been timed that way in the first place.

Before spending significant effort fixing difficult timing paths, verify that the SDC correctly represents the design intent.

Check:

* Primary clocks
* Generated clocks
* Clock relationships
* Input delays
* Output delays
* Clock uncertainty
* False paths
* Multicycle paths
* Clock groups
* Case analysis
* Mode definitions

An incorrect constraint can make a perfectly valid physical implementation appear broken.

The opposite is even more dangerous.

A bad constraint can hide a genuine timing failure.

Timing closure therefore includes **constraint validation**, not merely timing optimization.

## Look for Patterns, Not Individual Paths

When thousands of paths fail, manually repairing paths one at a time is usually the wrong approach.

Instead, classify the violations.

Ask whether they share:

* The same startpoint
* The same endpoint
* The same clock
* The same macro
* The same physical region
* The same logic cone
* The same high-fanout net
* The same scenario
* The same type of cell
* The same routing problem

Ten thousand timing violations may actually be the result of only a few underlying problems.

Finding those common causes is much more valuable than attacking ten thousand individual timing reports.

## Timing Closure Is a Tradeoff Problem

Physical design optimization rarely improves only one metric.

Consider upsizing a cell to improve timing.

It may:

Improve delay.

But also:

* Increase area
* Increase input capacitance
* Increase dynamic power
* Increase leakage power
* Increase downstream routing pressure

Replacing a high-Vt cell with a low-Vt cell may improve timing while increasing leakage.

Adding buffers may improve transition time while increasing area and power.

Moving cells closer together may improve timing while creating congestion elsewhere.

That is why timing closure is not simply optimization.

It is **multi-objective engineering**.

The goal is not the fastest possible design.

The goal is a design that meets:

* Timing
* Power
* Area
* Signal integrity
* IR drop
* Electromigration
* DRC
* Manufacturability

simultaneously.

## My Approach to Timing Closure

When I approach a timing problem, I generally think in the following sequence.

First, confirm that the timing constraints are valid.

Second, determine which path groups and scenarios are failing.

Third, review WNS, TNS, and violation counts together.

Fourth, inspect representative critical paths.

Fifth, determine whether delay is primarily cell-related, net-related, clock-related, or constraint-related.

Sixth, identify patterns across groups of violations.

Seventh, determine whether the proper fix belongs in:

* Synthesis
* Floorplanning
* Placement
* CTS
* Routing
* ECO optimization
* SDC
* Architecture

Only then should optimization begin.

After every significant change, timing must be re-evaluated across the relevant setup and hold scenarios.

This approach prevents the engineer from spending days repairing symptoms while leaving the real design problem untouched.

## The Difference Between Running Timing and Understanding Timing

Modern EDA tools are extremely powerful.

PrimeTime, Tempus, Fusion Compiler, ICC2, Innovus, and other modern implementation platforms can analyze and optimize millions of timing paths.

But the tool does not replace engineering judgment.

The engineer still has to determine:

* Whether the constraints are correct
* Which violations matter
* Why they occur
* Whether violations share a common cause
* Which optimization is appropriate
* What secondary effects the change may create
* Whether the resulting implementation is robust

A command can report the worst timing path.

A tool can optimize that path.

But deciding whether fixing that particular path is actually the right engineering decision still requires understanding the design.

## Conclusion

Timing closure is not the process of repeatedly running optimization until the negative slack disappears.

It is the process of making the physical implementation satisfy the intended timing behavior of the complete chip across the required operating conditions.

WNS tells us how bad the worst violation is.

TNS tells us how widespread the timing problem is.

Path groups tell us where the failures are concentrated.

MMMC analysis tells us whether the design is robust across operating conditions.

Root-cause analysis tells us why the violations exist.

And engineering judgment determines what should actually be changed.

After decades of working in ASIC physical design, one lesson remains consistent:

**The timing report gives you the numbers. The engineer has to understand the design behind those numbers.**

That is the difference between fixing negative slack and achieving timing closure.

— **Ruben Reyes**
Principal ASIC Physical Design Engineer