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. Building the Matrix

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

Building the Matrix

Multiply modes, voltage-temperature corners and interconnect corners, then choose the subset each check needs.

On this page

    Why it matters

    The full matrix of modes, process-voltage-temperature corners and interconnect corners is large. Teams do not run all of it for every check; they pick, for each check type, the scenarios that can be worst. Counting the matrix makes the cost visible and the selection rule explicit.

    Worked count

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    modes = ["func", "scan_shift", "scan_capture", "mbist"]
    pvt = ["ss_0p72v_125c", "ss_0p72v_m40c", "tt_0p80v_25c", "ff_0p88v_125c", "ff_0p88v_m40c"]
    rc = ["cworst", "cbest", "rcworst", "rcbest"]
    full = [(m, p, r) for m in modes for p in pvt for r in rc]
    assert len(full) == 80
    # starting plan: setup uses slow PVT with the two worst RC corners; hold uses fast PVT with the two best RC corners
    setup = [(m, p, r) for (m, p, r) in full if p.startswith("ss") and r in ("cworst", "rcworst")]
    hold = [(m, p, r) for (m, p, r) in full if p.startswith("ff") and r in ("cbest", "rcbest")]
    assert len(setup) == 16 and len(hold) == 16
    assert not set(setup) & set(hold)
    assert len(setup) + len(hold) == 32
    print("PASS: full matrix", len(full), "; starting plan", len(setup), "setup +", len(hold), "hold =", len(setup) + len(hold))

    The full matrix has 4 modes × 5 conditions × 4 interconnect corners = 80 scenarios. The starting plan above runs 16 slow-corner scenarios for setup and 16 fast-corner scenarios for hold, 32 in all. It is a starting guideline, not a rule: hold at slow corners and setup at fast corners can matter for clock-path variation, for hold at low voltage, and for modes with unusual clocking, so teams add scenarios when analysis shows they are needed. Note that the starting plan omits the fast low-voltage corners and the typical condition, which the temperature-inversion lesson says to add per voltage.

    A mode is more than a name

    Mode

    What differs

    Typical constraint difference

    Functional

    Normal operation

    Functional clocks, input and output delays, case values at their functional settings

    Scan shift

    Test data shifts through chains

    Slow scan clock; scan enable constant at 1 through case analysis

    Scan capture

    Test response captured

    Scan enable 0; at-speed clocks for delay test

    Memory test

    Built-in self test of memories

    Test clock; memory test controller active

    Diagram
    # not-run: SDC is not executable here
    # one mode's constraints: scan shift
    create_clock -name scan_clk -period 100 [get_ports scan_clk]
    set_case_analysis 1 [get_ports scan_enable]

    Each mode loads its own constraint file; the corner supplies the libraries and conditions and the interconnect corner supplies the extraction. A scenario is the triple of mode, process-voltage-temperature corner and interconnect corner, and its name should say all three.

    What the review looks for

    • The matrix, the starting plan and every addition to it are written down with a reason.

    • Every mode has a constraint file that was reviewed against that mode's intent.

    • Scenario names encode mode, PVT and RC corner, and are the same in every report.

    Common pitfall

    Running every mode in every corner by default. The cost grows with the product and the reports become unreadable; choose and document the subset, then extend it for evidence.

    Interview

    Be ready to multiply: 4 modes × 5 conditions × 4 RC corners, then say which subset you would run for setup.

    Check yourself A design adds a fifth mode and a sixth PVT condition. By how much does the full matrix grow?

    From 4 × 5 × 4 = 80 to 5 × 6 × 4 = 120 scenarios, an increase of 40 (50%).

    Related topics

    • Why Corners Exist

    • Next: Pruning Scenarios

    Previous

    75 / 183

    Next: Pruning Scenarios

    Up next

    Up nextPruning Scenarios

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Dominant Corner Analysis