AR# 2963: 12.1 Timing Closure - How do I find the paths that are not covered by Constraints/Advanced Analysis (i.e., coverage is less than 100%)?
12.1 Timing Closure - How do I find the paths that are not covered by Constraints/Advanced Analysis (i.e., coverage is less than 100%)?
In the "Constraints Covered" section of my timing report (.twr) file, only 87.1% (for example) is covered.
How do I find the 12.9% of the connections that are not covered?
The percentage of connections covered by timing constraints is given in a "% coverage" statistic. The statistic does not indicate the percentage of paths covered, but rather the percentage of connections covered.
Even if you have entered constraints that cover all paths in the design, this percentage might be less than 100%, as some connections are never included for timing analysis (for example, connections to the STARTUP component).
One example of this is seen when a Dual-Port RAM is instantiated and the SPO is left unused. The mapper will still connect the unused signals of the SPO portion of the RAM, forcing the tools to add these into the total connection count. However, as no setup/hold or propagation delays are associated with the pins, they cannot be constrained and will be counted against the "coverage" percentage in your design.
Another example is seen when a static pin drives a Look-Up Table (LUT) which combines with no other signals, and then drives other logic. This can happen at the start of a carry chain where a FORCE mode is used from a logic 1 or 0. Also, if terms for carry logic are connected to a CLB but are unused within the CLB, these connections will never be traced.
The coverage statistic is not a measure of the percentage of paths covered by the constraints; it is a measure of the percentage of total connections in the design that are covered by the constraints. Thus, a design can have all valid paths covered by constraints, but still have a coverage statistic that is not 100%.
Xilinx is aware of this confusion, and alternatives to the current report have been considered; but there are no plans to change it in the near future. A TSI (Time Spec Interaction) report option is available in software versions 3.1i and newer.
The most common reason that connection coverage does not reach 100% is that elements in the design have TIGs. If the Timing Tool encounters a TIG'd element when tracing a path, the trace will stop there, possibly leaving connections on the "other side" of the element uncovered. On the other hand, a path TIG (FROM TO TIG) will have all of its connections accounted for in the coverage statistic.
There are less obvious reasons for coverage that is under 100%. One is that the total number of connections in a design includes some that cannot be covered by constraints. An example of this is the connections on the STARTUP component. Another example is a case in which a static value drives an LUT that combines with no other signals and then drives other logic. This can happen at the start of a carry chain in which a FORCE (1 or 0) is used. Also, if terms for carry logic are connected to a CLB but go unused within the CLB, these connections will never be traced. (These are rare cases that are not handled well, but are uninteresting for timing analysis.)
Obviously, there are cases where a bug in either the speed files or (less commonly) the code results in a coverage statistic that does not meet 100%.
Note that if a default analysis is run with no PCF file, 100% connection coverage is still possible, even in these unusual cases. This is because, when the net analysis is done, an instantiation of every connection in the design is made to analyze the delay for each driver/load combination. There is simply no way to acquire path coverage for these cases in the existing code.
A common reason for connection coverage not reaching 100% is that elements in the design have TIGs. A TIG on an element will cause Trace to stop tracing the path, possibly leaving connections on the "other side" of the uncovered element.
On the other hand, a TIG on a path will have all of its connections accounted for in the coverage statistic.
The following command will analyze the "design.ncd" file using the timing constraints in the "design.pcf"; it will then generate a report called "output.twr" that includes delays of all uncovered paths:
trce -u design.ncd design.pcf -o output.twr
This will add a default group to the timing report that covers the unconstrained paths in the design (except for the connections that are never included or mentioned in the other resolutions).
Some paths are disabled by default, which can affect the coverage percentage; you can enable these paths in the Physical Constraints File (PCF) and in the User Constraints File (UCF). Some of the missing connections occur when the Path Tracing Controls are disabled (i.e., tbuf_i_o disabled, reg_sr_q disabled).
Enabling the path tracing controls for the set/reset paths (reg_sr_q) will allow all unconstrained paths to be seen. The following example illustrates how this can be done in the PCF and the UCF file:
Xilinx recommends enabling the "Reg_SR_Q" and "Reg_SR_Clk" path tracing controls for designs that have a synchronous element driving a Set/Reset pin. Other path tracing controls can also be enabled or disabled to allow the coverage of the design to be closer to 100%.