You are on page 1of 3

Finding and Resolving Unconstrained Endpoints

Doc Id: 038916  Product: Design Compiler;PrimeTime Last Modified: 04/29/2013 

Question:

I see unconstrained endpoints in the check_timing report, or if I use the report_timing command for 
a specific path, the report shows "Path is unconstrained". Why does this happen, and how do I resolve 
these unconstrained endpoints? 

Answer:

The "unconstrained endpoints" warning message identifies timing path endpoints that are not constrained 
for maximum delay (setup) checks. When Design Compiler or PrimeTime performs static timing analysis 
(STA) in the design, the tool determines the timing slack for a path by comparing the startpoint-to-
endpoint delay with the time span between the launch and capture clock edges. If there is any condition 
that prevents the tool from performing the setup timing check, the tool issues the "unconstrained 
endpoints" warning message. 

Possible Causes of Unconstrained Endpoints

No Timing Check Defined in the Library Cell

If there is no setup or hold timing check on the specified timing path endpoint, then there is no constraint 
for the endpoint. The checks are defined in the library cell as timing arcs, so you can determine whether a 
valid setup check exist in the specific cell pin by using the report_lib command: 

dc_shell> report_lib class -timing_arcs FD2


...
Arc Arc Pins
Lib Cell Attributes # Type/Sense From To When
----------------------------------------------------------------------------
FD2 s 0 hold_clk_rise CP D
1 setup_clk_rise CP D
2 rising_edge CP Q
3 rising_edge CP QN
4 clear_low CD Q
5 preset_low CD QN

In this example, the FD2 libcell has a valid setup constraint timing arc CP->D and also a hold constraint 
timing arc, so setup check would be performed on the D pin. 

No Clock

A timing check is based on a clock definition. If the launch or capture clock is missing, the analysis tool 
cannot find a reference launch clock edge for the startpoint delay or a capture clock edge for the endpoint 
delay. Therefore, no timing slack could be calculated, and the path is unconstrained, as reported by its 
endpoint in the check_timing command results. 
A clock can be a master clock or generated clock; make sure design constraints include complete clock 
definitions that successfully apply to the entire design scope. To verify clock constraints loaded onto the 
current design, use the report_clock command. 

In most common scenarios of clock-gating design, the analysis tool propagates the clock through clock-
gating cells to perform the setup timing check on its destination path endpoint. If the endpoint is listed in 
the check_timing report, but the clock is well-defined, then the clock might be blocked. For more 
information, see the following section. 

No Input or Output Delay

The clock definition alone could constrain a register-to-register path if the startpoint register and endpoint 
register exist in the same clock domain. However, for the paths starting at input ports or ending at output 
ports, the external launch time for the input path or the capture time for the output path should be 
specified to complete the timing check. Otherwise, the path is unconstrained. You can set these external 
constraints by using the set_input_delay and set_output_delay commands with the -clock option. 

The following figure and table summarize the timing path types and their required constraints:

Path type Must be constrained by...

Input path Input delay

Register-to-register path Clock

Output path Output delay

Pure combinational path Input and output delay

Clock Propagation is Blocked

If the timing constraints are complete, but you still get unconstrained endpoint warnings, then the clock 
might not be properly arriving at the cell where a timing check should occur. This blocked clock 
propagation usually occurs because of user-specified timing exceptions or disabled timing arcs, such as 
those specified by set_case_analysis, set_false_path, or set_disable_timing exceptions. 

Useful Debugging Methods and Reports

The Design Compiler and PrimeTime tools provide various commands to verify timing constraint 
completeness and to report or handle timing exceptions.
Design Compiler

According to the possible reasons described previously, when you get an unconstrained path, you can 
check library timing check definitions, clock definitions, and other timing constraints on ports. Finally, you 
can debug the reason why the clock is blocked from the timing path. The following table lists commonly-
used commands for this analysis:

Command Analysis description

check_timing Checks for unconstrained timing paths and clock-gating logic

report_port Shows unconstrained input and output ports and port loading

report_timing_requirements Shows all timing exceptions set on the design
report_clock Checks the clock definition and clock skew information

report_transitive_fanin Reports logic in the transitive fanin of specified sinks

report_disable_timing Shows all disabled timing arcs in the current design

report_lib -timing_arcs Shows available timing check for a specific library or library cell

Note: Setting case analysis exceptions on the enable pin of latch-based clock gating or integrated clock-
gating cells would not block clock propagation to the fanout registers, unless the 
case_analysis_sequential_propagation or case_analysis_propagate_through_icg variable is 
set to true.

PrimeTime

In addition to the commonly-used analysis commands available in Design Compiler, PrimeTime provides 
extra reports for unconstrained paths and analysis for timing exceptions. The check_timing -verbose
command displays detailed information about possible timing problems, which is very useful to diagnose 
unconstrained issues in the design. Also, unconstrained paths are listed in the default path group named 
"none", and the report_analysis_coverage -status_details untested command shows 
constraints that are not tested because of timing exceptions or incomplete timing constraints.

By default, PrimeTime does not show the timing report of unconstrained paths. Therefore, before doing 
analysis, you need to set the timing_report_unconstrained_paths variable to true. To trace timing 
exception command locations, you should also set the sdc_save_source_file_information variable 
to true before sourcing timing constraint scripts. To analyze timing exceptions when you suspect blocked 
clock propagation or unconstrained paths, use the following commands: 

• report_exceptions
• report_timing -exceptions all
If the unconstrained path is not caused by incorrect timing exceptions, and the number of disabled timing 
arcs is too large to isolate the problem area, you can find possible causes of the blocked path with a given 
startpoint and endpoint by using the Tcl script in SolvNet article 030124, "How Can I Find Out Where
A Timing Path Is Blocked?"

© 2018 Synopsys, Inc. All Rights Reserved. 

You might also like