Max transition and max capacitance checks

In short: Max-transition and max-capacitance are design-rule (DRV) checks that cap how slow a net may switch and how much load a cell may drive, so that cells stay within characterized limits — and signoff flags violations because a slow, overloaded net breaks timing accuracy, wastes power, and ages faster.

If you have ever opened a report_constraint in Synopsys PrimeTime or an Innovus check_drc summary and seen thousands of "max_transition" or "max_capacitance" violations, you have met two of the most misunderstood checks in physical design. Unlike setup and hold, these are not timing arcs — they are electrical design rules. Getting them right is what keeps your delay numbers trustworthy in the first place.

What a transition (slew) actually is

The transition time, or slew, is how long a signal takes to swing between two threshold voltages — commonly 10%–90% or 30%–70% of VDD, depending on the library. A net driven hard through a short wire might transition in 20 ps; a weak inverter driving a long, heavily-loaded route might take 400 ps. The library (.lib/Liberty) characterizes every cell's delay and output slew across a grid of input-slew and output-load points. Step outside that grid and the timing engine must extrapolate, and extrapolated delay is a guess, not signoff data.

Max-transition is really a guardrail on characterization validity. The max_transition attribute in Liberty is the largest input slew the vendor characterized. Beyond it, your STA numbers are unsupported by the model.

Max-capacitance: the load side of the same coin

Max-capacitance limits the total load a driver can legally see: the sum of pin capacitances of the sinks plus the wire (interconnect) capacitance of the route. A standard-cell datasheet gives each cell a max_capacitance derived from how much it can switch while still meeting its characterized output slew. The two checks are deeply linked: an overloaded net (max-cap violation) almost always produces a degraded slew (max-transition violation) as well, because a weak driver into a big capacitor charges slowly — \(t \approx R_{driver} \cdot C_{load}\).

Why signoff flags them — four concrete reasons

• Delay accuracy. A 500 ps slew on a net characterized only to 300 ps forces the STA tool to extrapolate the NLDM/CCS tables. Your reported setup slack is then fiction. This is the single biggest reason signoff is strict.
• Dynamic and short-circuit power. While both the NMOS and PMOS of a receiving gate are partly on during a slow transition, a crowbar current flows VDD→GND. Slow slews can add 10–20% to a block's dynamic power.
• Noise and crosstalk. A slow victim net sits in its sensitive region longer, so an aggressor coupling can push it over the switching threshold and cause a functional glitch.
• Reliability / aging. Sustained high-field stress during long transitions accelerates NBTI/HCI degradation, so a chip that passes at t0 can fail after a year.

A real example: a clock-gating enable in a 28 nm block drove 40 flops through one tiny CKLNQ cell. Measured slew was 680 ps against a 200 ps limit. The fix was a three-level buffer tree — four violations became zero, and the gated-clock power dropped measurably because the downstream gates stopped crowbarring.

How tools fix transition and cap violations

During optimization, Innovus (optDesign) and Fusion Compiler / IC Compiler II run DRV-fixing passes that apply a small toolbox:

• Driver upsizing: swap X1 for X4 — lower \(R_{driver}\), faster edge. Cheap, but costs area and input cap (which can push the violation upstream).
• Buffer insertion: break a long RC route into segments so each driver sees a bounded load. This is the workhorse fix.
• Fanout splitting / cloning: replicate the driver so the sinks divide across copies.
• Layer promotion / wide wires: route on a thicker metal to cut resistance on long nets.

Where the limits come from — and how you set them

There are two sources. First, the library: every cell carries a max_transition and max_capacitance in its .lib. Second, your SDC: you can tighten them globally with set_max_transition and set_max_capacitance on a clock group, a net, or the whole design. A common strategy is to set a stricter design-level transition on clock nets (say 100 ps) than on data (say 250 ps), because clock-edge quality directly sets your skew and jitter budget. The tool always honors the tightest applicable limit.

A sensible fixing order

Chasing DRVs blindly wastes runtime. Experienced PD engineers fix in this order: resolve max-cap and max-transition before final timing closure, because a slow slew inflates delay and will mask or fake setup violations. Fix the worst offenders (high fanout, long nets) first — they often clear dozens of smaller flags at once. Only then re-run report_timing. This is closely related to other electrical signoff gates such as the minimum pulse-width check and clock skew and jitter analysis, which together decide whether your clock network is physically buildable.

Want to run these checks hands-on with real Synopsys and Cadence flows? The CourseTron Physical Design track walks you from a .lib file to a clean DRV signoff, with graded lab exercises on buffer-tree construction.

For teams that would rather have the DRV-clean netlist delivered, the design-services group at Avecas VLSI design services runs production signoff flows, while hands-on classroom training is available through ChipXpert's VLSI programs.

FAQ

Is max-transition a timing check or a DRV?

It is a design-rule (DRV) check, not a timing arc. But it affects timing indirectly: a slew beyond the characterized limit makes the delay tables extrapolate, so your setup and hold numbers become unreliable until the transition is fixed.

Which should I fix first, max-cap or max-transition?

They usually travel together — an overloaded net is also a slow net. Fixing max-cap (by buffering or splitting fanout) typically clears the max-transition flag on the same net automatically, so attack the load first.

Can I just loosen the SDC limits to make violations disappear?

Only up to the library's own max_transition/max_capacitance. You can never legally exceed the characterized ceiling in the .lib — doing so means your signoff timing is built on extrapolated, unsupported data.

Why do slow transitions increase power?

During a slow edge both transistors in the receiving gate conduct simultaneously for longer, creating a short-circuit (crowbar) current from VDD to ground on every switch. This adds to dynamic power on top of the normal CV²f charging.