|
|
|
|
|
The Timing Analyzer can help you resolve some of the most frequently encountered design problems. This section describes common problems and solutions.
Asynchronous feedback paths in a design can cause many paths to be reported that may not actually be timing problems. The most common cases are feedback paths through asynchronous Set or Reset to banks of flip-flops, like a state machine or a counter. Another example is the construction of latches from function generators, which are built using asynchronous feedback paths.
To exclude specific nets that create feedback paths, such as an illegal-state Reset logic loop for a state machine, you can use the Exclude Paths with Nets command to exclude any paths that contain those nets from the timing report.
With the Control Path Tracing command, you can control some asynchronous points through logic; for example, you can exclude the asynchronous Reset of a flip-flop or TBUF input to output.
If you entered timing constraints before compiling your design with the mapper, you can use the Timing Analyzer to verify whether your constraints were met. The following example of portions of a Timing Analysis report shows how the Timing Analyzer finds paths that did not meet timing constraints; five errors occurred and three constraints were not met.
=========================================================================
Timing constraint: TS01 = MAXDELAY FROM TIMEGRP "FFS" TO TIMEGRP "FFS"
2000.000000 pS PRIORITY 0 ;
1 item analyzed, 1 timing error detected.
Maximum delay is 3.340ns.
-------------------------------------------------------------------------
Slack: -1.340ns path $1N11 to $1N11 relative to
2.000ns delay constraint
Path $1N11 to $1N11 contains 2 levels of logic:
Path starting from Comp: CLB.K (from $1N19)
To Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- --------
CLB.XQ Tcko 1.830R $1N11
$1N11
CLB.F2 net (fanout=2) e 0.380R $1N11
CLB.K Tick 1.130R $1N11
$1N15
$1N11
-------------------------------------------------
Total (2.960ns logic, 0.380ns route) 3.340ns (to $1N19)
(88.6% logic, 11.4% route)
.
.
.
3 constraints not met.
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Setup/Hold to clock ck1_i
---------------+------------+------------+
| Setup to | Hold to |
Source Pad | clk (edge) | clk (edge) |
---------------+------------+------------+
res_i | 6.202(R)| |
start_i | 2.213(R)| 0.000(R)|
---------------+------------+------------+
.
.
.
Table of Timegroups:
-------------------
TimeGroup PADS:
BELs:
OUT D C CLR
TimeGroup FFS:
BELs:
$1N11
Timing summary:
---------------
Timing errors: 5 Score: 15874
Constraints cover 5 paths, 0 nets, and 5 connections (100.0% coverage)
Design statistics:
Maximum path delay from/to any node: 10.716ns
Analysis completed Wed Feb 24 14:29:35 1999
-------------------------------------------------------------------------
The Timing Analyzer can report clock skew, which is the difference between the time a clock signal arrives at the source flip-flop in a path and the time it arrives at the destination flip-flop on the same clock net. Clock skew occurs most often when global routing is not used to route clock nets, because other routing is less predictable. The arrival of clock signals at different times can affect the required clock period. This section describes negative and positive clock skew and how the Timing Analyzer reports clock skew.
When the destination is clocked before the source, the clock skew is called negative clock skew. Negative clock skew means that the clock period must be longer than the path delay plus the amount of clock skew between the flip-flops. Negative clock skew is illustrated in the next figure.
Figure 2.15 Negative Clock SkewWhen the source is clocked first, the clock skew is called positive clock skew. Positive clock skew means that the clock period could be shorter than the path delay by the minimum amount of clock skew. The Timing Analyzer does not account for positive clock skew; it truncates positive clock skew to zero. Positive clock skew is illustrated in the following figure.
Figure 2.16 Positive Clock SkewThe Timing Analyzer uses the timing constraints specified in the Physical Constraints File (FPGAs) or the VM6 design file (CPLD); it does not infer extra timing constraints. The Timing Analyzer accounts for clock skew for all register to register paths. The following example shows the clock skew portion of a Timing Constraints Analysis report.
Slack: 12.667ns path SOURCE to DEST relative to
4.633ns total path delay
-2.300ns clock skew
15.000ns delay constraint
Path SOURCE to DEST contains 2 levels of logic:
Path starting from Comp: CLB_R14C13.K (from SIG_CLK)
To Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- --------
CLB_R14C13.YQ Tcko 2.090R SOURCE
BEL_SOURCE.FFY
CLB_R14C14.C4 net (fanout=1) 1.533R DATA_SRC_DST
CLB_R14C14.K Tdick 1.010R DEST
BEL_DEST.FFY
-------------------------------------------------
Total (3.100ns logic, 1.533ns route) 4.633ns (to SIG_CLK)
(66.9% logic, 33.1% route)
You can use Analyze 
Query Nets to generate a Query Nets report to display the clock skew across specific clock nets. See the “Querying for Information” section of the “Using the Timing Analyzer” chapter for the procedure to generate a Query Nets Report, an example of a Query Nets Report, and information on the report format.
To determine system-level clock speed, you must add any external delay to paths that travel off-chip. This way, the Timing Analyzer includes this external delay when calculating the delay for the path. There is no default delay; the Timing Analyzer does not add off-chip delay unless you specify it. See the XILINX Software Conversion Guide from XACTstep v5.x.x to XACTstep vM1.x.x for information on how to specify these delays with the OFFSET constraint in the UCF (User Constraints File) file.