Design Rule Violations (DRVs) in VLSI: Max Transition, Max Capacitance and Max Fanout

A design can close setup and hold timing and still be blocked from sign-off by a long list of design rule violations (DRVs): max transition, max capacitance and max fanout. These are electrical checks, not logical ones. They make sure every driver is used inside the range its library model was characterized for, so the delay numbers the timer reports can be trusted and the silicon behaves like the model.

DRVs are also among the most frequent questions in physical design interviews, and in practice they are often the first thing that blows up after placement, after CTS and after a late ECO. This guide explains what each DRV checks, where the limits come from, how the tools prioritize and fix them, and then works through illustrative examples, a debugging flowchart, interview questions, an FAQ and a summary.

Related reading: Static Timing Analysis (STA) in VLSI, Placement Optimization, Clock Tree Synthesis (CTS) and Signal Integrity and Crosstalk.

What DRVs are (and what they are not)#

In the physical design flow the word "DRC" usually means physical design rules: spacing, width, enclosure and so on, checked against layout geometry. DRVs are different. They are electrical design rules checked on the netlist plus parasitics, and they are reported by the implementation tool and by STA. The three classic DRVs are:

1. Max transition (max slew): the transition time at a pin must not exceed a limit.
2. Max capacitance: the total capacitance a driver output sees (wire plus pin capacitance of all loads) must not exceed a limit.
3. Max fanout: the fanout load driven by an output must not exceed a limit.

Some flows also check min capacitance (a driver loaded below the smallest load it was characterized for) and min transition, but these are rare in practice. Clock nets usually get their own, tighter transition limits.

DRVs and timing are linked but separate. A path can meet setup with a DRV on it, and a DRV-clean design can still fail timing. The reason DRVs matter even when slack is positive is that the slack itself may be wrong if the cell is being used outside its model.

Why the limits exist#

A standard cell's timing is stored in Liberty (.lib) lookup tables indexed by input transition and output load. The characterization covers a finite range of both. When a cell sees a slower input slew or a larger load than the table covers, the tool has to extrapolate, and extrapolated delay and slew values can be badly inaccurate. Max transition and max capacitance limits keep the design inside the table.

There are good physical reasons too:

• Slow edges cost power. While an input sits between the thresholds, both the pull-up and pull-down networks conduct, so short-circuit power rises with slew.
• Slow edges are noise-sensitive. A victim net with a slow transition spends longer in the switching region, so a coupling aggressor can shift its delay or inject a glitch more easily. See Signal Integrity and Crosstalk.
• Slow edges hurt clocks. On a clock tree, a degraded slew increases insertion delay variation and can distort the clock duty cycle; see Minimum Pulse Width and Duty Cycle.
• Heavily loaded drivers carry high current, which feeds into IR drop and electromigration risk on the driver output and nearby wires.

Where the limits come from#

DRV limits arrive from three places, and the tool uses the most restrictive value that applies to each pin:

A few practical points:

• Transition thresholds matter. The library defines which percentage points are used to measure slew (for example 10–90% or 20–80% of the supply) through attributes such as slew_lower_threshold_pct_rise, and may scale it with slew_derate_from_library. A "200 ps" limit means nothing until you know the measurement points.
• Clock and data can differ. SDC lets you set a tighter set_max_transition on clock paths than on data paths. Many teams do exactly that, because clock slew affects skew, duty cycle and min pulse width.
• Max fanout is a count of fanout load, not of pins. Each input pin carries a fanout_load value (often 1), and the sum is compared with max_fanout. Many libraries do not define a fanout limit at all, so it often comes only from SDC.

How tools treat DRVs in the flow#

Most implementation tools give DRV fixing higher priority than timing optimization by default: they will accept a small timing loss to clear a max transition or max capacitance violation. Expect DRV work at each stage:

• Synthesis and physical synthesis: high-fanout nets are buffered and drivers sized using wire-load or placement-based estimates. See Physical Synthesis.
• Placement optimization: this is where most data-path DRVs are fixed, using estimated parasitics from the placed netlist.
• High-fanout nets such as reset, scan enable and some select lines are usually handled by a dedicated high-fanout synthesis step, and clock nets are kept ideal until CTS.
• CTS: the clock tree is built to its own transition and capacitance targets, so clock DRVs should be close to zero right after CTS.
• Post-route: real extracted parasitics replace estimates. Long routes and detours often add new transition violations, which is why the post-route ECO always includes a DRV pass.
• Sign-off STA: max transition and max capacitance are checked across all corners. Max fanout is often treated as an implementation guideline rather than a sign-off criterion, as long as transition and capacitance are clean.

The open-source OpenROAD resizer is a useful public reference for how this works: its repair_design command inserts buffers to repair max slew, max capacitance and max fanout violations and on long wires, and resizes gates to normalize slews. It also offers slew and capacitance margins so the design can be "over-repaired" before routing, because placement-based parasitics cannot predict routed parasitics exactly.

Worked example 1: a max capacitance violation (illustrative)#

The numbers below are made up for teaching and do not come from any real library.

A small driver BUF_X1 has max_capacitance = 50 fF on its output. It drives eight loads with an input pin capacitance of 1.5 fF each, over a routed net of 250 µm with an extracted wire capacitance of about 0.18 fF/µm.

• Pin load: 8 × 1.5 fF = 12 fF
• Wire load: 250 µm × 0.18 fF/µm = 45 fF
• Total: 57 fF, against a limit of 50 fF, so the slack is −7 fF.

Notice that the wire, not the pins, dominates. Three possible fixes:

• Upsize the driver to BUF_X4, whose limit (say 200 fF) covers the load comfortably. Simple, but it raises the input capacitance seen by the previous stage.
• Split the net with a buffer near the far cluster of loads, so each segment is well below the limit.
• Improve placement so the loads sit closer to the driver, reducing the wire term. This is often the right fix when the violation comes from a scattered cluster.

Worked example 2: a max transition violation on a long net (illustrative)#

A data net leaves a register in one corner of a block and travels about 600 µm to a single load near the other corner. The constraint is set_max_transition 150 ps on data paths. A generic DRV report might look like this (format simplified, values illustrative):

Pin Limit Actual Slack u_core/u_alu/U123/A 150 212 -62 (VIOLATED)

The driver output slew is fine. The problem is the wire resistance: the slew degrades as the edge travels along the RC line, so the violation appears at the far-end load pin, not at the driver. Upsizing the driver helps only a little, because the wire R is in series. The effective fix is to insert a repeater around the middle of the route, so each half sees roughly a quarter of the RC product of the full wire. On the upper metal layers with lower resistance, promoting the route (layer assignment) can also fix it with no new cell.

A common mistake here is to keep upsizing the driver until the report clears. That raises power and the load on the previous stage while barely helping the far-end slew.

Worked example 3: a high-fanout net (illustrative)#

An enable signal drives 64 flip-flop enable pins (fanout_load 1 each) and the SDC sets set_max_fanout 32. The fanout is 64 against a limit of 32.

A balanced fix builds a buffer tree: the original driver feeds four buffers, and each buffer drives 16 loads placed near it. Each driver is now at fanout 4 or 16, well under the limit, and transition and capacitance also improve because each buffer drives a short, local net.

Cloning is the alternative: duplicate the original driver (for example the register that generates the enable) and split the loads between the copies by location. Cloning keeps the logic depth the same, so it is preferred when the path is timing-critical; a buffer tree adds a stage of delay.

Fixing DRVs: a practical order#

1. Check the constraints before the design. Wrong library limits, a missing clock transition constraint or a set_max_transition applied to the wrong objects create false violations, and false passes.
2. Separate clock DRVs from data DRVs. Clock DRVs point to CTS settings, NDRs or clock gating placement; data DRVs point to placement and buffering.
3. Group by driver. One weak driver on a big net can produce dozens of pin-level transition violations. Fix the driver or net once rather than chasing every pin.
4. Prefer the cheapest fix that clears the violation with margin: layer promotion or a placement tweak first, then sizing, then buffering or cloning.
5. Watch for side effects. Buffering adds delay and cells; upsizing increases input capacitance and leakage, and can create new violations upstream. Hold timing can also shift.
6. Re-run timing, SI and DRV checks after every ECO, in all corners. Slow corners usually show the worst transition violations.

Special cases worth knowing#

• Ideal and don't-touch nets. Clock nets before CTS and nets marked ideal or don't-touch are often excluded from DRV fixing. If the tool reports violations it will not fix, check these attributes first.
• Ports. Input ports need a realistic set_driving_cell or set_input_transition, otherwise the input slew is assumed ideal and the first stage hides a real problem. Output ports need a realistic set_load.
• Macros and hard IP. Pins on memories and IP have their own limits in the IP's Liberty model. A long route to a macro pin is a frequent source of post-route transition violations.
• Multi-corner differences. A DRV can exist only in the slow corner, or only at a specific voltage. Check which corners your sign-off requires.
• Tie cells and spare cells can create small max fanout or capacitance violations if many pins share one tie cell.

Interview questions and answers#

Q1. What are DRVs in physical design? Electrical design rules on the netlist: max transition, max capacitance and max fanout (sometimes min capacitance). They keep each cell inside the range its library was characterized for, so timing and power analysis remain accurate.

Q2. Why do we need a max transition limit if timing is met? Because the timing number may be wrong when the cell is outside its characterized table, and slow edges increase short-circuit power and crosstalk sensitivity. A positive slack built on extrapolated delay is not trustworthy.

Q3. Where do DRV limits come from, and which one wins? From Liberty defaults, Liberty pin attributes and SDC constraints. The tool applies the most restrictive applicable limit.

Q4. How do you fix a max transition violation on a long net? Insert a repeater along the net or promote it to a lower-resistance layer. Upsizing the driver helps little when the wire resistance dominates.

Q5. How do you fix a max capacitance violation? Upsize the driver, split the load with a buffer, or reduce the wire capacitance by moving loads closer or rerouting.

Q6. Buffer tree or cloning for a high-fanout net? Cloning keeps the logic depth and suits timing-critical nets; a buffer tree is cheaper in area but adds a stage of delay.

Q7. Which has higher priority in optimization, DRVs or timing? By default most tools fix DRVs first, accepting a small timing cost.

Q8. Why might DRVs appear only after routing? Placement-stage estimates use approximate parasitics. Real routes add detours and resistance, so slews degrade further than predicted. That is why some flows over-repair with a slew or capacitance margin before routing.

FAQ#

Is a DRV the same as a DRC? No. DRC usually means physical layout rules checked on geometry. DRVs are electrical limits on transition, capacitance and fanout checked by the implementation and STA tools.

Is max fanout really a sign-off check? It depends on the team. Many flows treat it as a guideline and sign off on transition and capacitance, which capture the electrical effect directly.

Should clock nets have a different transition limit? Usually yes, and tighter, because clock slew affects skew, duty cycle and minimum pulse width checks.

Can I waive a small transition violation? Only under your project's waiver process and after confirming the delay calculation is still inside the characterized range. Small violations on non-critical pins are sometimes waived, but that is a project decision, not a default.

Summary#

• DRVs are electrical rules: max transition, max capacitance and max fanout (plus occasional min checks).
• They exist to keep cells inside their characterized Liberty tables, and to control power, noise sensitivity and reliability.
• Limits come from Liberty defaults, Liberty pin attributes and SDC; the most restrictive applies.
• Tools usually fix DRVs before timing. Expect new DRVs after routing because real parasitics are worse than estimates.
• Fix long-wire transition problems with repeaters or layer promotion, capacitance problems with sizing or splitting, and fanout problems with buffer trees or cloning.
• Always re-check timing, SI and DRVs in all corners after each fix.

References#

• Liberty Reference Manual, Version 2007.03 (library-level default_max_transition, default_max_capacitance, default_max_fanout and pin-level limits): https://people.eecs.berkeley.edu/~alanmi/publications/other/liberty07_03.pdf
• OpenROAD Gate Resizer documentation, repair_design: https://openroad.readthedocs.io/en/latest/main/src/rsz/README.html
• OpenSTA, the open-source static timing analyzer: https://github.com/The-OpenROAD-Project/OpenSTA
• J. Bhasker and R. Chadha, Static Timing Analysis for Nanometer Designs: A Practical Approach, Springer, 2009: https://doi.org/10.1007/978-0-387-93820-2