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
  • Constraints & SDC Fundamentals20
  • Delay Graph & Path Analysis16
  • Beyond Setup and Hold16
  • Multi-Corner Multi-Mode Signoff16
    • Corner and Mode Matrix Design
      • Why Corners Exist
      • Building the Matrix
      • Pruning Scenarios
      • Dominant Corner Analysis
    • Library Sets and Operating Conditions
    • Signoff vs Implementation Views
    • MMMC Debug Playbook
  • OCV, AOCV, POCV and Variation16
  • Crosstalk and Noise16
  • ECO and Closure16
  • STA Debug Playbook16
  • STA Interview Prep26
  • Capstone Timing Signoff Lab4
Loading lesson

‹Corner and Mode Matrix Design
  1. Topics
  2. Static Timing Analysis
  3. Multi-Corner Multi-Mode Signoff
  4. Corner and Mode Matrix Design
  5. Dominant Corner Analysis

Part 5 · Multi-Corner Multi-Mode · All levels

Dominant Corner Analysis

A scenario dominates another when it is at least as bad at every endpoint; ownership tables show which scenario drives each endpoint.

On this page

    Why it matters

    When thousands of endpoints fail in several scenarios, engineers need to know which scenario to fix against. If one scenario is worse everywhere, fixing it fixes the others. If not, each scenario owns some endpoints and the work has to be split. Dominance and ownership make that visible.

    Worked example

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    slack = {
        "S1_ss_cworst":   [0.05, 0.12, -0.02, 0.30, 0.08],
        "S2_ss_rcworst":  [0.07, 0.10,  0.01, 0.28, 0.20],
        "S3_ss_cold_cw":  [0.04, 0.15,  0.03, 0.35, 0.09],
        "S4_tt":          [0.20, 0.25,  0.18, 0.40, 0.30],
    }
    names = list(slack)
    def dominates(a, b):
        return all(x <= y for x, y in zip(slack[a], slack[b]))
    dominated = sorted({b for a in names for b in names if a != b and dominates(a, b)})
    assert dominated == ["S4_tt"]
    assert not dominates("S1_ss_cworst", "S2_ss_rcworst") and not dominates("S2_ss_rcworst", "S1_ss_cworst")
    owner = [min(names, key=lambda s: slack[s][i]) for i in range(5)]
    assert owner == ["S3_ss_cold_cw", "S2_ss_rcworst", "S1_ss_cworst", "S2_ss_rcworst", "S1_ss_cworst"]
    failing = [i for i in range(5) if slack[owner[i]][i] < 0]
    assert failing == [2] and owner[2] == "S1_ss_cworst"
    print("PASS: dominated", dominated, "; owners", owner, "; failing endpoint owned by", owner[2])

    S4 (typical) is dominated by every slow scenario, as expected. No slow scenario dominates another: S1 is worse at endpoints 2 and 4, S2 at endpoints 1 and 3, S3 at endpoint 0. The only failing endpoint (index 2, slack -0.02 ns) is owned by S1, so the fix is judged in S1 and rechecked in the others. Endpoints owned by different scenarios need different fixes: a fix that helps in the cold corner may not help in the hot one.

    Ownership table

    Endpoint

    Owner

    Slack (ns)

    Next worst scenario

    0

    S3_ss_cold_cw

    0.04

    S1 (0.05)

    1

    S2_ss_rcworst

    0.10

    S1 (0.12)

    2

    S1_ss_cworst

    -0.02

    S2 (0.01)

    3

    S2_ss_rcworst

    0.28

    S1 (0.30)

    4

    S1_ss_cworst

    0.08

    S3 (0.09)

    What the review looks for

    • A table of how many failing endpoints each scenario owns, so effort goes where it matters.

    • Failing endpoints with different owners are triaged separately.

    • After a fix, the owner and the runner-up scenario are both rechecked: the runner-up can become the new owner.

    Common pitfall

    Fixing the owner scenario only. At endpoint 2 the runner-up has 0.01 ns of slack; a fix that costs 0.02 ns elsewhere moves the problem to the next scenario.

    Interview

    Use the terms: dominated scenario, scenario ownership, runner-up.

    Check yourself Endpoint 3 is owned by S2 with 0.28 ns slack, and S1 has 0.30 ns. If a fix improves S2 by 0.05 ns and leaves S1 unchanged, what is the new slack?

    0.30 ns, owned by S1: the fix helps only until the next scenario becomes the worst.

    Related topics

    • Pruning Scenarios

    Previous

    77 / 183

    Next: Library Sets and Operating Conditions

    Up next

    Up nextLibrary Sets and Operating Conditions

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Corners Exist
    • Building the Matrix