Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • STA Glossary
  • STA Metrics Reference
  • STA Mastery Cheatsheet
  • Timing Paths and Checks16
    • What STA Checks
      • STA Versus Simulation
      • The Timing Graph
      • Path Types and Endpoints
      • Why STA Is Pessimistic by Design
    • Setup and Hold Checks
    • Clocks in Timing Analysis
    • Delay Models
  • Constraints & SDC Fundamentals20
  • Delay Graph & Path Analysis16
  • Beyond Setup and Hold16
  • Multi-Corner Multi-Mode Signoff16
  • OCV, AOCV, POCV and Variation16
  • Crosstalk and Noise16
  • ECO and Closure16
  • STA Debug Playbook16
  • STA Interview Prep26
  • Capstone Timing Signoff Lab4
Loading lesson

‹What STA Checks
  1. Topics
  2. Static Timing Analysis
  3. Timing Paths and Checks
  4. What STA Checks
  5. Path Types and Endpoints

Part 1 · Timing Paths and Checks · All levels

Path Types and Endpoints

Paths are classified by where they start and end: register to register, input to register, register to output, input to output.

On this page

    Why it matters

    Each kind of path is constrained differently. A register-to-register path needs only clocks. An input-to-register path also needs an input delay saying when the outside world presents data. Knowing the four kinds tells you which constraints each endpoint depends on, and which missing constraint explains an unconstrained endpoint.

    The four path types

    Path type

    Starts at

    Ends at

    What constrains it

    Register to register

    Flop (or latch) clock pin

    Flop data pin

    The clock(s) alone

    Input to register

    Input port

    Flop data pin

    Clock plus an input delay relative to a clock

    Register to output

    Flop clock pin

    Output port

    Clock plus an output delay relative to a clock

    Input to output

    Input port

    Output port

    Input and output delays against a (virtual) clock (a combinational feed-through)

    What counts as a startpoint or an endpoint

    • Startpoints: the clock pin of a sequential cell (launching at its active clock edge) and primary input ports. Latch data-to-output arcs also continue paths through a latch, which the time-borrowing lessons cover.

    • Endpoints: the data pin of a sequential cell (where setup and hold are checked against the capture clock) and primary output ports. Clock gating enable pins and asynchronous reset pins are also checked, with their own rules.

    • A path is timed only if both its ends are constrained. Combinational logic between an unclocked input and an unconstrained output has no requirement, so STA reports nothing for it.

    Path groups

    Tools group paths, typically by the capture clock, so a report can list the worst path of each group. This matters for prioritisation: a fast clock domain can hide behind a slow domain's much larger violation if only the single worst path chip-wide is reported. The path-group lessons in the delay graph section cover the weighting; here the point is that grouping follows the endpoint.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    # Classify paths by endpoint kind and report which constraints each depends on.
    paths = [
        ("ff_a/CK", "ff_b/D"), ("in_x", "ff_b/D"), ("ff_a/CK", "out_y"), ("in_x", "out_y"),
    ]
    def kind(p):
        s, e = p
        s_reg = s.endswith("/CK")
        e_reg = e.endswith("/D")
        return {(True, True): "reg2reg", (False, True): "in2reg",
                (True, False): "reg2out", (False, False): "in2out"}[(s_reg, e_reg)]
    needs = {"reg2reg": {"clock"}, "in2reg": {"clock", "input_delay"},
             "reg2out": {"clock", "output_delay"}, "in2out": {"clock", "input_delay", "output_delay"}}
    kinds = [kind(p) for p in paths]
    assert kinds == ["reg2reg", "in2reg", "reg2out", "in2out"]
    assert needs["in2out"] == {"clock", "input_delay", "output_delay"}
    print("PASS: path kinds", kinds)

    Common pitfall

    Assuming every path is timed. A path from an input port with no input delay, or to an output port with no output delay, has no timing requirement and silently disappears from the report. Count unconstrained endpoints as part of every signoff review.

    Interview

    Asked how many path types there are, give the four and attach a constraint to each. The follow-up is nearly always: what happens if the input delay is missing? Answer: the path is unconstrained, not passing.

    Check yourself A design has 10,000 flops and the report shows 9,940 constrained endpoints. What do you do?

    Find the 60 unconstrained endpoints and explain each: a missing clock, a missing input or output delay, or a deliberate exception. Unconstrained is not the same as passing, and the count must reach zero (or be justified) before signoff.

    Related topics

    • The Timing Graph

    • Next: Why STA Is Pessimistic by Design

    Previous

    8 / 183

    Next: Why STA Is Pessimistic by Design

    Up next

    Up nextWhy STA Is Pessimistic by Design

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • STA Versus Simulation