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. Why STA Is Pessimistic by Design

Part 1 · Timing Paths and Checks · All levels

Why STA Is Pessimistic by Design

STA picks the worst case at every step, so its answers are safe but sometimes too cautious; knowing the sources tells you which pessimism is removable.

On this page

    Why it matters

    A signoff tool that is occasionally optimistic would pass chips that fail. So STA is built to err toward failure: it assumes the worst when it cannot know better. That is correct for safety and expensive for performance. An engineer who understands each source of pessimism can tell the difference between a real violation and one that disappears when the pessimism is removed correctly.

    Where the pessimism comes from

    Source

    What STA assumes

    Removable by

    All paths are real

    Every structural path can toggle

    Justified false paths and constants

    Worst-case corners

    The delay-maximising corner for setup, the delay-minimising corner for hold

    Nothing: this is the intent; use the right corners (see the MMMC section)

    Variation derates

    Launch and capture paths see opposite extremes of variation

    Common path pessimism removal for the shared part; statistical methods

    Simultaneous worst case

    Every cell on the path is at its worst at once

    Statistical or depth-based derating

    Coupling

    Aggressors switch in the worst direction at the worst time

    Timing windows that show aggressors cannot overlap

    Margin

    Uncertainty added for jitter and unknowns

    Better estimates as the design matures

    A worked example: opposite extremes on a shared path

    Consider launch and capture flops fed by the same clock tree. They share the first 0.8 ns of the clock path. If STA derates the launch path late and the capture path early, it applies those opposite derates even to the shared 0.8 ns, which cannot physically be both. That is pure pessimism, and the common-path lesson shows how it is removed.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    # Pessimism on a shared clock segment when launch is derated late and capture early.
    shared = 0.80            # ns of clock path common to launch and capture
    late, early = 1.05, 0.95 # illustrative derates
    launch_shared = shared * late     # 0.84
    capture_shared = shared * early   # 0.76
    pessimism = launch_shared - capture_shared
    assert abs(pessimism - 0.08) < 1e-9
    print("PASS: removable pessimism on the shared segment =", round(pessimism, 3), "ns")

    What the review looks for

    • A violation that is small compared with a known pessimism source is investigated for that source before any RTL or ECO change.

    • Pessimism removal uses a documented, standard method; it is never replaced by adding positive margin by hand.

    • Corners and derates are chosen to model real silicon, not to make the report green.

    Common pitfall

    Fixing pessimism by loosening a constraint. Making a failing path pass by lowering a derate, cutting uncertainty or adding a false path removes the safety margin without removing the risk. Remove pessimism only with methods that are physically justified.

    Interview

    The mature answer to "Is STA pessimistic?" is yes, deliberately, and then names two removable sources (shared clock path, impossible simultaneous worst case) and one that is not (the delay-maximising corner for setup).

    Check yourself Is it acceptable to lower the clock uncertainty by 50 ps to fix a path that fails by 30 ps?

    Not on its own. Uncertainty represents real jitter and estimation error; reducing it to pass a path is lowering the margin, not removing pessimism. Change it only if you have evidence the original value was too large for this design stage, and say so in the review.

    Related topics

    • Path Types and Endpoints

    • RTL: Skew and Uncertainty

    Previous

    9 / 183

    Next: Setup and Hold Checks

    Up next

    Up nextSetup and Hold Checks

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • STA Versus Simulation
    • The Timing Graph