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
    • Clock Definition & Uncertainty
    • Generated Clocks & Dividers
    • I/O Timing & Boundary Contracts
    • Exceptions & Audit Policy
    • Environment and Design Rules
      • Case Analysis and Disable Timing
      • Max Transition and Capacitance
      • Operating Conditions and Units
      • Constraint Sanity Checks
  • 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

‹Environment and Design Rules
  1. Topics
  2. Static Timing Analysis
  3. Constraints & SDC Fundamentals
  4. Environment and Design Rules
  5. Case Analysis and Disable Timing

Part 2 · Constraints and SDC · All levels

Case Analysis and Disable Timing

set_case_analysis sets a constant that propagates through logic; set_disable_timing removes a specific arc from the graph.

On this page

    Why it matters

    Many paths exist structurally but are irrelevant in a given mode: a test path in functional mode, the other input of a mux whose select is fixed. Constants remove them in a way that is visible and consistent. Disabling an arc is more surgical and more dangerous.

    The two commands

    Diagram
    # not-run: SDC is not executable here
    set_case_analysis 0 [get_ports scan_enable]                  ;# functional mode: scan enable low
    set_case_analysis 1 [get_pins clk_mux/S]                     ;# select the second clock
    set_disable_timing [get_cells mux_x] -from I0 -to Z          ;# remove one arc from the graph

    set_case_analysis

    set_disable_timing

    What it does

    Fixes a pin to 0 or 1; constants propagate and disable the arcs they block

    Removes the named arc without changing logic values

    Scope

    Everything downstream of the constant

    Only the named arc

    Evidence

    A mode definition: the pin really is constant in that mode

    A reason that the arc is not a real path (for example a loop break)

    Risk

    Wrong constant analyses the wrong mode

    Hides paths that do pass through the arc

    example.py
    1
    2
    3
    4
    5
    6
    # Constant propagation through an AND: one input at 0 forces the output to 0 and disables the other input's arc
    def and_out(a, b): return a & b
    # scan_enable = 0 feeding an AND with a data input: output follows data (non-controlling constant 1) or is forced (controlling 0)
    assert and_out(0, 1) == 0 and and_out(0, 0) == 0     # 0 is controlling: output constant, arc from the other input is dead
    assert and_out(1, 1) == 1 and and_out(1, 0) == 0     # 1 is non-controlling: the other input still matters
    print("PASS: a controlling constant (0 into AND) disables the other input's timing arc")

    A 0 into an AND gate is controlling: the output is 0 whatever the other input does, so no timing path goes through the other input. A 1 is non-controlling and leaves the arc live. Tools apply exactly this rule when propagating case analysis constants.

    What the review looks for

    • Each constant is listed per mode with its source in the mode definition; constants for one mode are not applied in another.

    • Case analysis reports are read: the number of arcs disabled by each constant matches expectations.

    • set_disable_timing is rare and documented; most uses should be replaced by constants or fixed logic.

    Common pitfall

    Leaving a functional-mode constant in the file when running test-mode analysis. The test paths vanish and the report looks clean. Constants belong to a mode, and each mode is a separate scenario.

    Interview

    Explain controlling versus non-controlling values and why propagating a constant removes arcs.

    Check yourself A mux select is constant 0. What happens to the paths through input I1?

    They disappear from analysis: with the select fixed to 0 the mux output follows I0, so the arc from I1 to the output is disabled by the propagated constant.

    Related topics

    • Clock Muxes and Case Analysis

    • Next: Max Transition and Capacitance

    Previous

    38 / 183

    Next: Max Transition and Capacitance

    Up next

    Up nextMax Transition and Capacitance

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Operating Conditions and Units
    • Constraint Sanity Checks