From Constraints to Confidence: Executing Timing Checks
You've defined your clocks, specified I/O delays, and declared timing exceptions. Your constraints are complete, your design is loaded, and OpenSTA is ready. Now comes the moment of truth: running timing analysis to discover if your design meets its timing requirements. This is where theory meets reality—where you learn if your chip will run at the target frequency or if optimization work lies ahead.
Running timing analysis isn't just executing a command and hoping for green checks. It's about understanding what the tool is reporting, interpreting slack values, tracing critical paths, and making informed decisions about optimization priorities. This module teaches you to run comprehensive timing analysis, read timing reports like a professional, and extract the insights needed for timing closure.
Setup Analysis: Checking Maximum Delays
What Is Setup Analysis?
Setup analysis verifies that data arrives at capture flip-flops before the required time. It checks the maximum delay paths to ensure signals propagate fast enough to be captured reliably on the next clock edge.
Setup Question: "Does data arrive early enough?"
Analysis Corner: Slow corner (SS) where delays are longest and meeting timing is hardest.
Running Setup Analysis in OpenSTA
Basic Setup Check
report_checks -path_delay max
This reports the worst (most critical) setup path in the design.
Multiple Paths
# Report 10 worst setup paths
report_checks -path_delay max -path_count 10
Specific Endpoint
# Check paths to specific flip-flop
report_checks -path_delay max -to [get_pins data_reg[7]/D]
Paths from Specific Source
# Check paths from particular register
report_checks -path_delay max -from [get_pins state_reg[*]/Q]
Unconstrained Paths
# Find paths without timing constraints
report_checks -path_delay max -unconstrained
This should ideally return nothing—all paths should be constrained.
Example Setup Analysis Command Sequence
# Complete setup analysis workflow
puts "=========================================="
puts "Setup Timing Analysis"
puts "=========================================="
# Check worst path
puts "\nWorst Setup Path:"
report_checks -path_delay max -path_count 1
# Check top 10 failing paths
puts "\nTop 10 Critical Setup Paths:"
report_checks -path_delay max -path_count 10 -slack_max 0
# Check all negative slack paths
puts "\nAll Setup Violations:"
report_checks -path_delay max -slack_max -0.001
# Verify all paths constrained
puts "\nUnconstrained Setup Paths:"
report_checks -path_delay max -unconstrained
Key Options:
-path_count N: Report N paths-slack_max X: Only paths with slack ≤ X-slack_min X: Only paths with slack ≥ X-group_count N: Paths per endpoint group
Hold Analysis: Checking Minimum Delays
What Is Hold Analysis?
Hold analysis verifies that data remains stable after the clock edge long enough for the capture flip-flop to latch it. It checks minimum delay paths to ensure signals don't arrive too quickly.
Hold Question: "Does data stay stable long enough?"
Analysis Corner: Fast corner (FF) where delays are shortest and hold violations are most likely.
Running Hold Analysis in OpenSTA
Basic Hold Check
report_checks -path_delay min
Reports the worst (most critical) hold path.
Multiple Hold Paths
# Report 10 worst hold paths
report_checks -path_delay min -path_count 10
Hold Violations Only
# Paths with negative slack
report_checks -path_delay min -slack_max -0.001
Complete Hold Analysis
puts "=========================================="
puts "Hold Timing Analysis"
puts "=========================================="
# Worst hold path
puts "\nWorst Hold Path:"
report_checks -path_delay min -path_count 1
# All hold violations
puts "\nAll Hold Violations:"
report_checks -path_delay min -slack_max -0.001
# Critical hold paths (< 100ps margin)
puts "\nCritical Hold Paths (slack < 100ps):"
report_checks -path_delay min -slack_max 0.1
Setup vs. Hold: Running Both
Complete Analysis Script
# Read design and constraints
read_liberty lib/cells_tt.lib
read_verilog netlist/design.v
link_design top_module
read_sdc constraints/design.sdc
# ============================================
# Setup Analysis
# ============================================
puts "\n================================================"
puts "SETUP TIMING ANALYSIS"
puts "================================================"
report_checks -path_delay max -path_count 5
report_worst_slack -max
# ============================================
# Hold Analysis
# ============================================
puts "\n================================================"
puts "HOLD TIMING ANALYSIS"
puts "================================================"
report_checks -path_delay min -path_count 5
report_worst_slack -min
# ============================================
# Summary
# ============================================
puts "\n================================================"
puts "TIMING SUMMARY"
puts "================================================"
report_tns
report_wns
Understanding Timing Reports
Anatomy of a Timing Report
When you run report_checks, OpenSTA produces a detailed report showing the complete timing path. Let's dissect a real example:
Sample Setup Timing Report
Startpoint: launch_ff/Q (rising edge-triggered flip-flop clocked by sys_clk)
Endpoint: capture_ff/D (rising edge-triggered flip-flop clocked by sys_clk)
Path Group: sys_clk
Path Type: max
Point Incr Path
---------------------------------------------------------
clock sys_clk (rise edge) 0.00 0.00
clock network delay (ideal) 1.00 1.00
launch_ff/CK (DFF_X1) 0.00 1.00 r
launch_ff/Q (DFF_X1) 0.18 1.18 r
inv1/A (INV_X1) 0.02 1.20 r
inv1/Y (INV_X1) 0.06 1.26 f
and1/A (AND2_X1) 0.01 1.27 f
and1/Y (AND2_X1) 0.08 1.35 r
nand1/A (NAND2_X1) 0.02 1.37 r
nand1/Y (NAND2_X1) 0.07 1.44 f
capture_ff/D (DFF_X1) 0.00 1.44 f
data arrival time 1.44
clock sys_clk (rise edge) 10.00 10.00
clock network delay (ideal) 1.00 11.00
clock uncertainty -0.20 10.80
capture_ff/CK (DFF_X1) 0.00 10.80 r
library setup time -0.09 10.71
data required time 10.71
---------------------------------------------------------
data required time 10.71
data arrival time -1.44
---------------------------------------------------------
slack (MET) 9.27
Breaking Down the Report
Header Section
Startpoint: launch_ff/Q
Endpoint: capture_ff/D
Path Group: sys_clk
Path Type: max
- Startpoint: Where the data originates (flip-flop output)
- Endpoint: Where data must arrive (flip-flop input)
- Path Group: Clock domain for this path
- Path Type:
max(setup) ormin(hold)
Data Path Section
Point Incr Path
---------------------------------------------------------
clock sys_clk (rise edge) 0.00 0.00
clock network delay (ideal) 1.00 1.00
launch_ff/CK (DFF_X1) 0.00 1.00 r
launch_ff/Q (DFF_X1) 0.18 1.18 r
Column Meanings:
- Point: Pin or connection point
- Incr: Incremental delay (this stage only)
- Path: Cumulative delay from clock edge
- r/f: Rising or falling transition
Key Path Elements:
Clock Launch Edge (0.00ns)
- Starting reference point
Clock Network Delay (+1.00ns → 1.00ns)
- Time for clock to reach launch flip-flop
- Includes clock tree latency
Clock-to-Q Delay (+0.18ns → 1.18ns)
- Propagation through launch flip-flop
- From Liberty characterization
Combinational Logic Delays
inv1/A → inv1/Y : +0.06ns (inverter delay) and1/A → and1/Y : +0.08ns (AND gate delay) nand1/A → nand1/Y : +0.07ns (NAND gate delay)- Each gate adds propagation delay
- Wire delays included in pin-to-pin times
Data Arrival Time (1.44ns)
- Total time for data to reach capture flip-flop input
Required Time Section
clock sys_clk (rise edge) 10.00 10.00
clock network delay (ideal) 1.00 11.00
clock uncertainty -0.20 10.80
capture_ff/CK (DFF_X1) 0.00 10.80 r
library setup time -0.09 10.71
data required time 10.71
Key Elements:
Capture Clock Edge (10.00ns)
- Next rising edge (one period after launch)
Clock Network Delay (+1.00ns → 11.00ns)
- Clock tree delay to capture flip-flop
Clock Uncertainty (-0.20ns → 10.80ns)
- Subtracts margin for jitter/skew
- Makes timing more pessimistic (conservative)
Library Setup Time (-0.09ns → 10.71ns)
- Data must arrive this much before clock
- From flip-flop characterization
Data Required Time (10.71ns)
- Deadline for data arrival
Slack Calculation and Interpretation
The Slack Equation
Setup Slack
Slack = Required_Time - Arrival_Time
= 10.71ns - 1.44ns
= 9.27ns
Hold Slack
Slack = Arrival_Time - Required_Time
(Note: Hold calculation is opposite of setup)
Interpreting Slack Values
Positive Slack (slack > 0)
slack (MET) = 9.27ns
Meaning: Timing requirement is met with margin
- Data arrives 9.27ns before the deadline
- You could slow down the logic by 9.27ns and still meet timing
- Or increase frequency until slack approaches zero
Zero Slack (slack = 0.00)
slack (MET) = 0.00ns
Meaning: Timing requirement is barely met
- No margin for error
- Manufacturing variations could cause failure
- Not recommended for production (need margin)
Negative Slack (slack < 0)
slack (VIOLATED) = -0.35ns
Meaning: Timing requirement failed
- Data arrives 0.35ns after the deadline
- Design will not work at target frequency
- Must fix before tape-out
Slack and Frequency Relationship
Example: Path with -0.5ns slack at 200 MHz (5ns period)
Current: Period = 5.0ns, Slack = -0.5ns
Required delay reduction: 0.5ns
To meet timing:
Reduce path delay by 0.5ns, or
Increase period by 0.5ns
New frequency = 1000 / (5.0 + 0.5) = 182 MHz
You can achieve 182 MHz with current implementation, need optimization for 200 MHz.
Worst Negative Slack (WNS) and Total Negative Slack (TNS)
WNS: Worst Negative Slack
report_wns
Output Example
Worst Setup Slack: -0.35ns
Worst Hold Slack: 0.12ns
WNS is the single worst path slack in your design.
TNS: Total Negative Slack
report_tns
Output Example
Total Negative Setup Slack: -12.45ns (across 87 paths)
Total Negative Hold Slack: 0.00ns
TNS is the sum of all negative slacks.
Interpretation:
- WNS = -0.35ns: Most critical path needs 0.35ns improvement
- TNS = -12.45ns across 87 paths: Many paths failing, average violation ~0.14ns
- Large TNS with small WNS: Many slightly failing paths (easier to fix)
- Large WNS with small TNS: Few badly failing paths (harder to fix)
Path Details: Understanding the Journey
Startpoint Analysis
Typical Startpoints:
Flip-Flop Output
Startpoint: state_reg[3]/QMost common—data launching from sequential element
Input Port
Startpoint: data_in[7]Data coming from outside the chip
Clock Pin
Startpoint: clk (clock source)Clock propagation path
Identifying Startpoint Type
Startpoint: launch_ff/Q (rising edge-triggered flip-flop clocked by sys_clk)
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Instance Description
The description tells you:
- Element type (flip-flop, latch, input port)
- Trigger type (rising edge, falling edge, level-sensitive)
- Clock association
Endpoint Analysis
Typical Endpoints:
Flip-Flop Data Input
Endpoint: capture_ff/DData being captured by sequential element
Output Port
Endpoint: data_out[3]Data leaving the chip
Latch Enable
Endpoint: latch_cell/ENControl signal for latch
Endpoint Information
Endpoint: capture_ff/D (rising edge-triggered flip-flop clocked by sys_clk)
Critical for understanding timing checks being performed.
Data Path Tracing
Following the Signal
The report shows the complete data propagation:
launch_ff/Q → inv1/A → inv1/Y → and1/A → and1/Y → nand1/A → nand1/Y → capture_ff/D
At Each Stage:
inv1/A (INV_X1) 0.02 1.20 r
inv1/Y (INV_X1) 0.06 1.26 f
- inv1/A: Input pin (arrival time: 1.20ns, rising)
- inv1/Y: Output pin (arrival time: 1.26ns, falling)
- Incr 0.06: This gate added 0.06ns delay
- r→f: Signal inverted (rising to falling)
Transition Tracking: r (rising) and f (falling) help understand logic polarity through the path.
Clock Path Analysis
Launch Clock Path
clock sys_clk (rise edge) 0.00 0.00
clock network delay 1.00 1.00
launch_ff/CK 0.00 1.00 r
Clock travels from source through clock tree to launch flip-flop.
Capture Clock Path
clock sys_clk (rise edge) 10.00 10.00
clock network delay 1.00 11.00
clock uncertainty -0.20 10.80
capture_ff/CK 0.00 10.80 r
Clock travels to capture flip-flop, arriving at next clock edge.
Clock Skew
If launch and capture have different network delays:
Launch clock network delay: 1.00ns
Capture clock network delay: 1.20ns
Clock skew = 1.20 - 1.00 = 0.20ns (positive skew)
Positive skew (capture later): Helps setup, hurts hold Negative skew (capture earlier): Hurts setup, helps hold
Practical Example: Complete Analysis Session
Example Design: 8-bit Counter
Setup
# Load design
read_liberty lib/stdcells_tt.lib
read_verilog netlist/counter_mapped.v
link_design counter
# Load constraints
read_sdc constraints/counter.sdc
# Verify setup
report_clocks
check_timing
Run Analysis
# ============================================
# Setup Check
# ============================================
puts "\n=== Setup Timing ==="
report_checks -path_delay max -path_count 3
# Output:
# Startpoint: count_reg[0]/Q
# Endpoint: count_reg[7]/D
# slack (MET) = 8.45ns
#
# Startpoint: count_reg[1]/Q
# Endpoint: count_reg[7]/D
# slack (MET) = 8.52ns
#
# Startpoint: count_reg[2]/Q
# Endpoint: count_reg[7]/D
# slack (MET) = 8.60ns
# ============================================
# Hold Check
# ============================================
puts "\n=== Hold Timing ==="
report_checks -path_delay min -path_count 3
# Output:
# Startpoint: count_reg[5]/Q
# Endpoint: count_reg[5]/D
# slack (MET) = 0.15ns
#
# Startpoint: count_reg[3]/Q
# Endpoint: count_reg[3]/D
# slack (MET) = 0.18ns
#
# Startpoint: count_reg[0]/Q
# Endpoint: count_reg[0]/D
# slack (MET) = 0.22ns
# ============================================
# Summary
# ============================================
puts "\n=== Timing Summary ==="
report_worst_slack -max
report_worst_slack -min
# Output:
# Worst Setup Slack: 8.45ns (MET)
# Worst Hold Slack: 0.15ns (MET)
#
# Timing Requirements: PASSED
Interpretation:
- Setup: 8.45ns slack—very comfortable margin
- Hold: 0.15ns slack—met but closer (typical)
- Critical path: count_reg[0] → count_reg[7] (carry chain through adder)
- Hold critical: count_reg[5] (short local path)
Analyzing a Violation
Setup Violation Example
Startpoint: alu_a_reg[7]/Q
Endpoint: result_reg[15]/D
slack (VIOLATED) = -0.28ns
Path delay: 5.28ns
Required time: 5.00ns
Violation: 0.28ns
Analysis Questions:
What's the path?
- ALU input register → multiplier logic → result register
- Long combinational path (multiplier)
Why is it failing?
- Path delay (5.28ns) exceeds clock period budget (5.00ns)
How to fix?
- Option 1: Pipeline the multiplier (add register stage)
- Option 2: Use faster multiplier cell library
- Option 3: Reduce clock frequency to 190 MHz (5.26ns period)
Hold Violation Example
Startpoint: bypass_reg/Q
Endpoint: next_stage_reg/D
slack (VIOLATED) = -0.05ns
Path delay: 0.03ns
Required time: 0.08ns
Violation: 0.05ns
Analysis:
- Problem: Path is too fast (only 0.03ns delay)
- Cause: Direct connection or very short logic path
- Fix: Add delay buffers (50ps each)
Advanced Reporting Options
Filtering and Grouping
By Clock Domain
# Only paths in specific clock domain
report_checks -path_delay max -group sys_clk
By Path Group
# Separate report for each clock domain
report_checks -path_delay max -group_count 5
Through Specific Logic
# Paths through critical module
report_checks -path_delay max -through [get_pins alu/*]
Format Options
Brief Format (summary only)
report_checks -path_delay max -format summary
Full Detail (default)
report_checks -path_delay max -format full_clock
Fields to Display
report_checks -path_delay max \
-fields {capacitance slew fanout}
Shows additional timing details like transition times and loads.
Output Redirection
Save to File
# Redirect output to file
report_checks -path_delay max > setup_timing.rpt
report_checks -path_delay min > hold_timing.rpt
Append to File
report_checks -path_delay max >> timing_all.rpt
report_checks -path_delay min >> timing_all.rpt
Summary
Running timing analysis reveals whether your design meets timing requirements:
- Setup analysis (
-path_delay max) checks maximum delays at slow corner - Hold analysis (
-path_delay min) checks minimum delays at fast corner - Timing reports show complete path details with incremental and cumulative delays
- Slack = Required_time - Arrival_time (positive = pass, negative = fail)
- Path components: Startpoint → Data path → Endpoint, with clock paths defining required times
Key skills you've developed:
- Running setup and hold checks systematically
- Reading and interpreting timing reports
- Understanding slack calculations
- Tracing signal paths through the design
- Identifying critical paths and violations
- Using report options for targeted analysis
With timing analysis mastered, you can now verify designs, identify bottlenecks, and guide optimization efforts. Every timing report tells a story about your design's performance—learning to read that story is essential for successful digital design. In the next module, you'll learn to fix timing violations and optimize for timing closure.
