BeginnerQuestion 294 of 97Source PDF page undefined

What are the four standard timing path types STA classifies paths into, and why does that classification matter?

From PDVerse PnR Interview Handbook · pdVerse Mentor Guide

Short Answer

The four path types are input-to-register (I2R), register-to-register (R2R), register-to-output (R2O), and input-to-output (I2O) -- the standard 4-way STA path group classification. This classification matters because different path types often need different constraint treatment (I/O delays for boundary paths, clock relationships for R2R paths) and different optimization priority during timing closure.

Technical Reference DiagramWhat are the four standard timing path types STA classifies paths into, and why does that classification matter?
What are the four standard timing path types STA classifies paths into, and why does that classification matter?, illustrating the physical design concept.

Technical Explanation

  • The four path types: input-to-register (I2R), register-to-register (R2R), register-to-output (R2O), and input-to-output (I2O).
  • This is the standard 4-way STA path group classification, and it isn't just labeling -- it determines what kind of constraint governs each path (I/O delays at the boundary for I2R/R2O/I2O, clock relationships for R2R).
  • The critical path is the path with the greatest negative slack among ALL of these types combined -- the goal is positive slack with margin across every type, not just R2R.
  • report_timing -group [get_path_groups {I2R R2R R2O I2O}] is how the four path-group types are actually queried and reported in a live design.

Common Mistake

The Trap: Focusing timing closure effort only on R2R paths since they're usually the most numerous, while I2O/I2R/R2O boundary paths (governed by I/O delay constraints) quietly carry their own violations.

Follow-up Question & Model Response

"Why might I2O paths specifically need more careful review than R2R paths, even if there are fewer of them?"

Candidate Model Response: Because I2O paths depend entirely on externally-specified I/O delay constraints rather than on the design's own internal clock relationships -- a wrong or unrealistic I/O delay assumption can make an I2O path look fine in STA while actually being wrong relative to the real system it interfaces with.

Practical Example

Debug Scenario: A design closes R2R timing cleanly but signoff still shows violations -- checking path-group breakdown reveals the remaining violations are all I2O paths, governed by input/output delay constraints that hadn't been reviewed as carefully as the internal clock paths.

Physical Design & Planning Handbook

Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.