BeginnerQuestion 8 of 95

What is data required time?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Data required time is the deadline the tool computes for a path: the latest moment data may arrive (for a setup check) or the earliest moment data may safely change (for a hold check) at the capturing flip-flop. It comes from the clock period, the capturing clock's own delay, and the cell's own setup or hold requirement.

Data required time built from clock period, capture clock latency, library setup/hold time, uncertainty, and CRPR credit — Technical Reference DiagramWhat is data required time?

Technical Reference DiagramWhat is data required time?

Technical Explanation

Required time is not just the clock period — it's a deadline built from several pieces added together.

For setup, the deadline is the next capturing edge, pulled earlier by margin. The tool starts from the clock period plus the capture clock's network delay, then subtracts the cell's setup time (from the library) and the clock uncertainty margin, to get a conservative deadline.
Common-path pessimism removal (CRPR) credits some of that margin back. Where the launch and capture clock paths share physical buffers, some of the pessimism added by analyzing each clock path independently isn't real, so the tool adds a CRPR credit back onto the required time.
For hold, the deadline moves the other direction. The tool computes an early boundary from the capture clock's delay plus the cell's hold time, then adds clock uncertainty (rather than subtracting it) and again removes common-path pessimism with CRPR.
The hold deadline doesn't reference the next cycle at all. Unlike setup, hold required time is anchored to the same clock edge that launched the data, which is exactly why hold checks don't depend on clock frequency.

Common Mistake

The trap: assuming data required time for setup is simply equal to the clock period.
It's a reasonable first guess, since the period is the most visible number in the constraint.
In reality the deadline also shifts with capture clock latency, the cell's own setup time from the library, clock uncertainty, and any CRPR credit — a design with a longer clock tree or a slower library cell has a tighter deadline than the raw period suggests.

Follow-up Question & Model Response

Why does clock uncertainty get subtracted from the setup deadline but added to the hold deadline?

Candidate Model Response: Uncertainty represents timing pessimism the tool applies to guard against clock jitter and skew it can't precisely predict. For setup, making the deadline earlier is the pessimistic direction — subtracting uncertainty does that. For hold, making the deadline later is the pessimistic direction, because it forces data to stay stable longer — so uncertainty gets added instead. Both directions are pessimistic on purpose; they just point opposite ways because setup and hold are opposite kinds of checks.

Practical Example

When a PLL team re-characterized clock jitter from 50 ps down to 25 ps, the reduced uncertainty term shifted every core path's setup required time later by 25 ps. That single change resolved roughly 1,200 setup violations across the design without touching a single gate.

Complete STA Handbook