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. STA Versus Simulation

Part 1 · Timing Paths and Checks · All levels

STA Versus Simulation

STA checks every path structurally and quickly; simulation checks function on chosen vectors. They answer different questions.

On this page

    Why it matters

    A gate-level simulation with a good testbench can still miss a timing failure, because the failing path may never be exercised by the vectors you ran. Static timing analysis removes that dependency: it examines all paths through the design and compares each against a timing requirement. Knowing exactly what that does and does not cover tells you which checks to rely on for signoff.

    What each method covers

    Question

    STA

    Simulation

    Does every register-to-register path meet setup and hold?

    Yes, all structural paths

    Only paths the vectors toggle, and only if delays are annotated

    Is the function correct?

    No: STA does not know the intended behaviour

    Yes, against a checker or reference

    Does a path ever actually toggle?

    No: it assumes any path can

    Yes, observable

    Is a clock domain crossing safe?

    For related clocks it checks setup and hold but cannot judge protocol safety; between asynchronous groups it checks nothing, so crossings need separate CDC verification

    Only for the scenarios run

    Is a glitch on a combinational node harmful?

    Not by itself (noise analysis is a separate step)

    Possibly, if the model is detailed enough

    How long does a full run take?

    Minutes to hours for a whole chip

    Hours to days for realistic activity

    The model behind the speed

    STA turns the netlist into a graph of cells and wires with delays on the edges (the next lessons build this). Computing the latest and earliest arrival time at every node is a linear pass through the graph, so cost grows with design size, not with the number of input vectors. That is why it can sign off a billion-gate design that simulation could never exercise exhaustively.

    What STA assumes

    • Every path can be exercised. A path through a mux whose select can never take the needed value is still timed unless you tell the tool (a false path or a case-analysis constant).

    • The constraints are right. STA checks the design against the clocks, input delays and exceptions you give it. Wrong constraints give a confident wrong answer.

    • The delay models are right. Library data, parasitics and the corner definition decide the numbers. A perfect analysis with the wrong corner proves nothing.

    Common pitfall

    Treating a clean STA report as proof the design works. STA says the timing requirements you wrote are met. It says nothing about whether those requirements describe the design that was intended. Function, constraints and crossings need their own checks.

    Interview

    When asked why you need both, answer with the split: simulation checks what the design does, STA checks whether it does it fast enough everywhere. Then name one thing each cannot see: a never-toggled slow path for simulation, an incorrect constraint for STA.

    Check yourself A path through a configuration register that is written once at boot fails STA by 0.3 ns. Simulation never failed. Is the STA result wrong?

    Not necessarily wrong. STA assumes the path can toggle. If the register really is static in operation, the right fix is an explicit, justified constraint (a constant or exception with evidence), not ignoring the report. If it is not static, simulation simply never exercised the failing case.

    Related topics

    • RTL: STA Foundations

    • Next: The Timing Graph

    Previous

    6 / 183

    Next: The Timing Graph

    Up next

    Up nextThe Timing Graph

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Path Types and Endpoints
    • Why STA Is Pessimistic by Design