Narla Ganesh asked 3 days ago
semiconductor answered 3 days ago
I think unconstrained endpoints in a check_timing report occur when timing paths are excluded from analysis due to specific directives in the SDC file, like false paths, case constraints, disable timing, or no-check settings. You often see these in sanity checks when the design intentionally excludes certain paths that don’t affect the overall functionality.
Let’s break it down:
False Paths: We use false paths to tell the tool that certain timing paths are irrelevant for timing analysis. For example, you might have debug or test logic paths that don’t influence the critical timing of the design. When you mark these as false paths, the tool doesn’t analyze them, leading to unconstrained endpoints.
Case Constraints: You might have design blocks with multiple modes of operation, and case constraints are used to define specific conditions or signal values for these modes. If an endpoint is constrained in one mode but not in others, it can show up as unconstrained in a generic timing check.
Disable Timing: Sometimes, we disable timing on certain cells or paths explicitly, like in test-related paths or when dealing with incomplete timing models. When timing is disabled, the endpoint effectively becomes unconstrained.
No-Check Directives: I’ve noticed we use no-check to bypass timing checks for specific paths. For example, in clock-gating logic or during ECO steps, you might use no-check to ignore paths temporarily. This also results in unconstrained endpoints.
You need to be careful with these directives because unconstrained endpoints can lead to missed timing violations if used incorrectly. I always recommend reviewing unconstrained endpoints in check_timing reports and ensuring they align with the design intent and functionality. It’s all about balancing design flexibility with accurate timing closure!
Please login or Register to submit your answer