In short: A minimum pulse width check verifies that every clock high phase and low phase (and set/reset de-assertion) stays wider than the library-specified limit, because a pulse narrower than that cannot reliably propagate through the flip-flop or latch and silently corrupts captured data.
When engineers first meet static timing analysis (STA) they obsess over setup and hold. Those answer "did data arrive in time relative to the clock edge?" But there is a second, quieter family of constraints that governs the clock signal itself: minimum pulse width and the related minimum period and minimum low/high time checks. A clock that toggles too fast, or a pulse that gets eaten alive by a glitch, will never latch anything correctly no matter how clean your data path is. This article explains what the check is, why the tool flags it, and how to read and fix a violation.
What a minimum pulse width check actually tests
Every sequential cell in a standard-cell library ships with characterized timing arcs. Among them is a min_pulse_width constraint, specified separately for the clock pin's high phase and low phase. Physically, when a clock edge arrives, the internal transmission gates and master/slave latches of a flip-flop need a finite amount of time to settle. If the opposite edge arrives before that settling completes, the internal node never reaches a valid logic level and the captured value is indeterminate — effectively metastable or simply wrong.
The check is deceptively simple arithmetic. The tool measures the time between a rising edge and the next falling edge at the clock pin (the high pulse), and between a falling and the next rising edge (the low pulse). It compares each against the library minimum. A typical 7nm flip-flop might require a minimum high pulse of roughly 40–60 ps; a mature 180nm part might require 0.5–1.0 ns. If the measured pulse is smaller, you get a violation with negative slack.
Why STA flags it — the real failure mechanism
Consider a shift register clocked at 2 GHz, period 500 ps, nominally 50% duty cycle so each phase is 250 ps. That looks safe. But the clock does not reach the flip-flop as drawn — it passes through a clock tree with ICGs (integrated clock gating cells), MUXes, and perhaps a glitchy combinational gate someone accidentally put in the clock path. Any of these can distort the duty cycle. A clock gater that opens late and closes early can shave a 250 ps high phase down to 90 ps. If the cell needs 110 ps high, STA reports a pulse-width violation.
The other classic source is glitches on asynchronous control. A reset de-assertion that bounces, or a combinationally generated clock (a huge anti-pattern) that produces a sliver pulse, both trigger the same check. The tool is warning you that a real sliver could appear in silicon and either partially clock a register or fail to clock it at all.
A worked numeric example
| Quantity | Value | Note |
|---|---|---|
| Nominal high phase at source | 250 ps | 50% of a 500 ps period |
| Duty-cycle degradation through tree | −140 ps | ICG + MUX skew between edges |
| Arrived high pulse at FF.CK | 110 ps | measured by STA |
| Library min high pulse | 125 ps | from the .lib arc |
| Slack | −15 ps | VIOLATION |
Notice the degradation comes from different insertion delays on the rising and falling edges of the clock as they traverse the tree. This is why pulse-width problems and clock skew are tightly related: the same tree asymmetry that produces skew between launch and capture also eats into the pulse at a single pin.
How the tools report and constrain it
In Synopsys PrimeTime you query these with report_min_pulse_width (or they appear under check_timing), and the designer can explicitly set expectations with set_min_pulse_width. In Cadence Tempus / Genus the check appears in the clock-gating and min-pulse-width timing reports; report_timing -check_type min_pulse_width surfaces the arc. Siemens (Mentor) Questa/Tessent flows also honor the same .lib constraints during test clock insertion, which matters hugely for at-speed scan where shift and capture clocks have very different pulse requirements.
Fixing a minimum pulse width violation
- Balance the clock tree edges. If rise and fall insertion delays differ, CTS should be re-run with duty-cycle awareness, or buffers with matched rise/fall chosen.
- Remove logic from the clock path. Never generate a clock combinationally; use proper ICG cells characterized for pulse behavior.
- Check the clock gater placement. A gater that enables too close to the active edge chops the pulse — move the enable earlier.
- Relax the frequency or duty cycle if the silicon genuinely cannot support the pulse, especially on legacy nodes.
- Validate the constraint. Sometimes the violation is a missing
create_clockwaveform definition, so the tool assumes a default that is unrealistically narrow.
Teams building real sign-off flows often pair this with a broader timing methodology review. If you are standing up a flow from scratch, the physical-design engineers at Avecas VLSI design services handle exactly this kind of corner-aware clock closure. For a structured walk through STA from first principles, see our companion piece on setup and hold time analysis.
Want to master STA, clocking, and sign-off hands-on with real PrimeTime and Tempus flows? Explore the CourseTron VLSI physical design and STA course and close your first clock tree with confidence.
Frequently asked questions
Is minimum pulse width the same as minimum period?
No. Minimum period limits how fast the full cycle may repeat; minimum pulse width limits how narrow a single high or low phase may be. A clock can satisfy the period requirement while still violating pulse width if its duty cycle is badly skewed.
Does minimum pulse width apply only to clocks?
Primarily to clock pins, but it also applies to asynchronous set and reset (clear/preset) pins, which have their own minimum active-pulse requirement so the register actually resets before the control de-asserts.
Why does my violation only appear at the slow corner?
Internal transistors are slowest at the slow PVT corner, so the cell needs a wider pulse to settle. The required minimum pulse width is largest there, making it the limiting corner for this check.
Can a pulse-width violation cause metastability?
Yes. A sub-minimum pulse can leave the internal storage node at an intermediate voltage, which is a classic trigger for metastable behavior and unpredictable captured data in silicon.