What is a max_transition violation, and why is it treated as a design rule rather than a slack-based check?

Short Answer

max_transition is a design-rule ceiling, defined in the standard cell library, on the largest transition time — how long a signal takes to swing between logic levels — that a cell's input or output pin is allowed to see. A violation is a hard design rule check (DRC) failure, verified against a fixed library limit, independent of whether the path around it has positive timing slack.

Technical Explanation

• What a transition time is. Every signal edge takes non-zero time to swing between logic levels — its transition time, sometimes called slew. A slow, gradual edge behaves electrically worse than a sharp one, even if the logical delay is otherwise fine.
• What max_transition limits. The library specifies, per cell or pin, the slowest transition time that cell is characterized and guaranteed to behave correctly for. max_transition (LIB) is that ceiling.
• Why it's a design rule check, not a slack check. Setup and hold compare two computed times against each other, and a path can have generous slack while still driving a pin with an unacceptably slow edge. A DRC instead compares one measured value against one fixed library limit, with no reference to clock period at all.
• Why it matters even with plenty of slack. A slow transition degrades a cell's own delay accuracy — most delay models are less reliable outside their characterized range — and increases short-circuit power. None of that shows up in a slack number.
• How it's reported. report_constraint (PT) with -all_violators lists max_transition violations separately from setup/hold, since fixing one (usually by upsizing or buffering) doesn't automatically fix the other.

Follow-up Question & Model Response

If fixing a max_transition violation by upsizing the driving cell makes that cell faster, could that same fix ever introduce a new hold violation?

Candidate Model Response: Yes. Upsizing a cell to sharpen its output transition typically reduces its cell delay, which speeds up the data path it drives. On a path that was already close to its hold limit, that extra speed can be exactly what pushes hold slack negative, since hold is a minimum-delay check that penalizes paths for arriving too early. This is why a max_transition fix, like a setup fix, needs a hold re-check on the same and any electrically coupled paths rather than being treated as an isolated, purely electrical change.