False Path, Disable Timing Path, and Case Analysis
In Static Timing Analysis (STA), we use timing exceptions to relax unnecessary paths, making timing closure easier. The three key timing exceptions are False Paths, Disable Timing Paths, and Case Analysis.
1. False Path (FP)
Definition:
A false path is a timing path that will never be activated during normal operation. Even though tools report violations on this path, it should be ignored.
🔹 Real-World Example:
In a design with two asynchronous clock domains (clk1
and clk2
), a data path exists but is not functionally used. Since the clocks are not related, timing closure on this path is unnecessary.
Fix: Ignore the path using a False Path constraint
Command Example (Synopsys PrimeTime, Cadence Tempus, Synopsys ICC2)
set_false_path -from [get_clocks clk1] -to [get_clocks clk2]
(This tells STA tools to ignore timing violations between clk1 and clk2.)
🛠Debugging a False Path
✔ Check Clocks: Verify if clocks are truly asynchronous using report_clocks
.
✔ Analyze Paths: Run report_timing
before and after applying set_false_path
.
✔ Confirm Functional Validity: Ensure no real data transfer occurs between these registers.
2. Disable Timing Path (DTP)
Definition:
A disable timing path removes a specific timing arc inside a combinational cell from analysis.
🔹 Real-World Example:
A multiplexer (MUX) has two inputs (A
and B
), but due to a control condition, the A → Y
path will never be active. The STA tool still analyzes it, causing unnecessary timing violations.
Fix: Disable the specific timing arc
Command Example (Synopsys PrimeTime, Cadence Tempus)
set_disable_timing U1 -from A -to Y
(Disables timing checks for path A → Y
inside instance U1
.)
🛠Debugging a Disabled Timing Path
✔ Check the cell: Use report_timing -from A -to Y
to confirm the arc exists.
✔ Confirm logic condition: Ensure the A → Y
transition is never functionally possible.
✔ Analyze tool impact: Verify the change in timing reports after applying set_disable_timing
.
3. Case Analysis (CA)
Definition:
Case analysis is used when a signal is statically fixed (0
or 1
) in a specific operation mode. This helps eliminate unnecessary timing paths.
🔹 Real-World Example:
A mode selection signal (MODE_SEL
) determines whether a circuit operates in Test Mode or Functional Mode. In Functional Mode, MODE_SEL = 1
, meaning all paths related to MODE_SEL = 0
should be ignored.
Fix: Apply Case Analysis to simplify timing
Command Example (Synopsys PrimeTime, Cadence Tempus)
set_case_analysis 1 [get_ports MODE_SEL]
(Forces MODE_SEL = 1
, ignoring timing paths associated with MODE_SEL = 0
.)
🛠Debugging Case Analysis
✔ Check the logic: Use report_timing
to see if paths related to MODE_SEL = 0
are removed.
✔ Confirm fixed behavior: Ensure MODE_SEL
is not dynamically changing.
✔ Use RTL Constraints: If the condition is permanent, fix it in the RTL instead of STA constraints.
4. Key Differences & Summary
Feature | False Path | Disable Timing Path | Case Analysis |
---|---|---|---|
What it Ignores | Entire timing path | A specific timing arc | Paths related to fixed conditions |
Used For | Async clock paths, functionally inactive paths | Unused logic within a cell | Statically fixed signals |
Example | Path between clk1 and clk2 |
A → Y transition in a MUX |
MODE_SEL = 1 removes MODE_SEL = 0 paths |
Command | set_false_path |
set_disable_timing |
set_case_analysis |
Debugging Tip | Ensure real async clocks | Verify timing arcs | Confirm fixed values |
5. Conclusion
- False Path: Used for entire paths that will never be active.
- Disable Timing: Used to remove specific arcs in combinational cells.
- Case Analysis: Used to fix signal values and simplify timing.