What do input and output delays describe?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
Input and output delays describe time spent outside your block — everything happening before a signal reaches your input pin, or after it leaves your output pin, relative to a reference clock. They are explicitly not the delay of the block's own internal input receiver or output buffer — a common beginner mistake is thinking set_output_delay models the output driver's own speed, when really it models whatever sits downstream (the receiving device's setup/hold requirement plus any board/interconnect delay).
Technical Explanation
- The whole point is to connect your block-level timing model to the real world beyond the block boundary — the device that launches data into your inputs, and the device that captures data from your outputs.
- Without them, static timing analysis at the block level would have no idea how much of the clock period is "already spent" before a signal crosses in, or how much time the receiver downstream actually needs after a signal crosses out.
- Both come in min and max flavors for the same reason any timing check does: max models the worst-case late arrival (drives setup), min models the worst-case early arrival (drives hold) — skipping either leaves half the picture unconstrained.
- Get the reference clock and edge right for every one of these — an input/output delay pointing at the wrong clock produces a plausible-looking but meaningless number.
Visual Verification
Input and output delays specify the external portion of the clock cycle spent outside the chip boundary on the PCB or external IC, leaving the remainder for internal block logic.
What To Check
- Warning sign: Only maximum values are supplied or ports reference the wrong clock edge.
- Inspect: Start with one named object in the report and trace it to the netlist, library, or SDC statement that created it.
- Correct: Return to the interface budget, apply required min/max and rise/fall intent, and review boundary timing paths.
Command Checks & Actions
- report_ports -input_delay [get_ports *]: shows boundary constraints and electrical assumptions
- report_ports -output_delay [get_ports *]: shows boundary constraints and electrical assumptions
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: They describe external timing relative to a clock; they are not delays of the block's input or output buffers.
- Stop before floorplanning when required logic or timing coverage is missing or unexplained.
Common Mistake
The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.
What The Interviewer Is Testing
Be ready to explain why this matters before floorplanning.
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