Showing posts with label Disable Timing Path. Show all posts
Showing posts with label Disable Timing Path. Show all posts

False Path, Disable Timing Path, and Case Analysis


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.