Why are input and output delays needed, and what do min and max mean?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Input and output delays exist because your block doesn't operate in isolation — timing "outside the box" (the external device driving into your input, or the external device receiving from your output) has to be modeled relative to your reference clock, or the block-level timing analysis is meaningless. An input delay says "here's when data launched externally can reach my input pin" — think of it as pre-paid budget already spent before the signal even crosses your boundary, leaving less time for your internal logic to work with.
Technical Explanation
- Input and output delays exist because your block doesn't operate in isolation — timing "outside the box" (the external device driving into your input, or the external device receiving from your output) has to be modeled relative to your reference clock, or the block-level timing analysis is meaningless.
- An input delay says "here's when data launched externally can reach my input pin" — think of it as pre-paid budget already spent before the signal even crosses your boundary, leaving less time for your internal logic to work with.
- An output delay says "here's how much timing budget the receiver outside my block needs after my output pin" — it's not the delay of your own output buffer, it's a placeholder for downstream logic and setup/hold you don't control.
- A simplified same-edge example makes the arithmetic concrete: with a 10 ns clock period and a 3 ns max input delay, roughly 7 ns is left for internal logic before you even subtract internal capture setup, uncertainty, and clock-related effects. With a 2 ns max output delay, the internal output-side budget is roughly 8 ns. These are teaching numbers, not full signoff equations — latency conventions and clock relationships still have to be modeled consistently for a real signoff number.
- Minimum values matter just as much as maximum ones — data that arrives too early can violate hold requirements just like data arriving too late violates setup. Don't treat min values as an afterthought.
- One counterintuitive but correct fact: output minimum delay can legitimately be negative under common receiver-hold conventions — the sign follows the interface timing equation, not a rule that "all delays must be positive." Always pull the sign/reference convention from the actual interface spec rather than assuming.
Command Checks & Actions
set_input_delay -clock [get_clocks clk] -max 0.3 [get_ports in1]Models the worst-case external arrival time at an input port relative to the reference clock -- the max side that drives the setup check at the chip boundary.
set_output_delay -clock [get_clocks clk] -min 0.2 [get_ports out1]Models the best-case required time at an output port, exercising the min/hold-side check at the boundary rather than the more commonly discussed max/setup side.
Common Mistake
The Trap: Using the clock period itself as both input and output delay, or inventing min values by copying max values.
Follow-up Question & Model Response
"Why use a virtual clock?"
Candidate Model Response: It can represent the external timing reference without requiring that clock to propagate through a physical port in the block.
Practical Example
Tapeout Scenario: If upstream data arrives between 0.5 ns and 3 ns after launch, model that range with the appropriate minimum and maximum input constraints. Modeling only the late arrival leaves the early-arrival assumption inadequately specified.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising