I have a design with a path similar to the following:
Figure 1: Design Path
All buffers have min/max delays of 1ns/2ns, with the exception of U3 which has a slow delay of 1.9ns instead of 2ns (represented with a slightly smaller buffer symbol). When I generate a timing report, I can see that the last pin which is common between the launch and capture paths is U4/Z, with a CRP of 2. However, the CRP value is less than I expect:
pt_shell> report_timing -from FF1/CP -to FF2/D \ -path_type full_clock_expanded ... Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLK) Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLK) Path Group: CLK Path Type: max Point Incr Path --------------------------------------------------------------- clock CLK (rise edge) 0.00 0.00 clock source latency 0.00 0.00 CLK (in) 0.00 0.00 r U1/Z (BUFFD1) 2.00 * 2.00 r U4/Z (BUFFD1) 2.00 * 4.00 r U5/Z (BUFFD1) 2.00 * 6.00 r UMUX/Z (OR2D1) 2.00 * 8.00 r FF1/CP (DFD1) 0.00 * 8.00 r FF1/Q (DFD1) 2.00 * 10.00 r FF2/D (DFD1) 0.00 * 10.00 r data arrival time 10.00 clock CLK (rise edge) 10.00 10.00 clock source latency 0.00 10.00 CLK (in) 0.00 10.00 r U1/Z (BUFFD1) 1.00 * 11.00 r U4/Z (BUFFD1) 1.00 * 12.00 r FF2/CP (DFD1) 0.00 * 12.00 r clock reconvergence pessimism 1.00 13.00 library setup time 0.00 * 13.00 data required time 13.00 --------------------------------------------------------------- data required time 13.00 data arrival time -10.00 --------------------------------------------------------------- slack (MET) 3.00 When I report the common point with report_crpr, I see that the reported common pin is U1/Z, which explains the lesser CRP value of 1:
pt_shell> report_crpr -from FF1/CP -to FF2/CP -setup
...
Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLK)
Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLK)
Common Point: U1/Z
Common Clock: CLK
Launching edge at common point: RISING
Capturing edge at common point: RISING
CRPR threshold: 0.02
Arrival Times Early Late CRP
---------------------------------------------------------------
Rise 1.000 2.000 1.000
Fall 1.000 2.000 1.000
---------------------------------------------------------------
Selection Details
---------------------------------------------------------------
Edge Match: Match, using rise CRP
---------------------------------------------------------------
clock reconvergence pessimism 1.000
I expected U4/Z to be reported as the common point since it is the last pin that appears in both the launch and capture clock paths. Why is this happening?
Answer:
Despite its initial appearance, this is not a bug. To understand why, let's take a closer look at the launch and capture paths traced in our example above:
Figure 2: Default Launch and Capture Paths
Since this is a setup path, the launch clock path to FF1/CP uses the latest arrival and the capture clock path to FF2/CP uses the earliest arrival. We see that there are actually two launch paths available to FF1/CP, but due to the slightly faster delay at U3 in the upper path, the lower path is chosen.
Based only on the timing report, we expected the common pin to be U4/Z resulting in a CRP value of 2. Let's call this the visual common point since it's the common point that we would deduce from visually analyzing the timing report. However, PrimeTime's CRPR algorithm computes a CRP value which comprehensively considers all possible clock paths to the launch and capture flops, rather than just the early/late paths which are shown in the timing report. This is called the topological common point since it's the common point which is valid for all possible paths.
Why does CRPR need to consider the other paths? To understand this, let's force PrimeTime to use the upper launch path so we can see what happens. We could do this by using set_disable_timing on U5, but this is not the best way to perform our experiment - it requires design knowledge to know that U5 is the right gate to disable, and disabling the connectivity completely may cause other issues. Instead of disabling the connectivity through U5, let's leave it in place and set an annotated delay to our expected common pin U4/Z which is so fast, the tool will only use a launch path through U4 as a last resort:
pt_shell> set_annotated_delay -cell -to U4/Z -max -1000
1
Figure 3: Alternative Launch Path Used
The timing report now becomes:
pt_shell> report_timing -from FF1/CP -to FF2/D \
-path_type full_clock_expanded
...
Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLK)
Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLK)
Path Group: CLK
Path Type: max
Point Incr Path
---------------------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLK (in) 0.00 0.00 r
U1/Z (BUFFD1) 2.00 * 2.00 r
U2/Z (BUFFD1) 2.00 * 4.00 r
U3/Z (BUFFD1) 1.90 * 5.90 r
UMUX/Z (OR2D1) 2.00 * 7.90 r
FF1/CP (DFD1) 0.00 * 7.90 r
FF1/Q (DFD1) 2.00 * 9.90 r
FF2/D (DFD1) 0.00 * 9.90 r
data arrival time 9.90
clock CLK (rise edge) 10.00 10.00
clock source latency 0.00 10.00
CLK (in) 0.00 10.00 r
U1/Z (BUFFD1) 1.00 * 11.00 r
U4/Z (BUFFD1) 1.00 * 12.00 r
FF2/CP (DFD1) 0.00 * 12.00 r
clock reconvergence pessimism 1.00 13.00
library setup time 0.00 * 13.00
data required time 13.00
---------------------------------------------------------------
data required time 13.00
data arrival time -9.90
---------------------------------------------------------------
slack (MET) 3.10
When this slightly faster launch path is used, the slack now improves by 0.1ns, from its original slack of +3.0ns to a new slack of +3.1ns. During operation of the device, both paths are equally valid launch paths and either path could be used. Looking back at the original timing path in the question section, if we had used a CRP value of 2 instead of 1, our slack would have been +4ns. This would have been optimistic since we have just proven that another alternative (and equally valid) path exists with a slack of +3.1ns!
In our example, using the visual common point U4/Z would have caused our slack to be improved to the point where other potential clock paths (not shown in the report) could have become more critical. To ensure this cannot happen, CRPR must ensure that all possible launch/capture paths are considered in the CRP computation rather than just the paths shown in the report by using the topological common point. This is not the same thing as using the earliest common pin in the path (which would simply be the root pin!), but is actually the latest common pin across all possible latency paths which are available to the device in operation.
Useful Analysis Tools
Two Tcl procedures are provided in this article to help explore and understand timing paths which have multiple possible clock paths. The first procedure is the compare_common_point procedure:
compare_common_point [get_timing_paths -path full_clock_expanded ...]
This procedure analyzes a collection of one or more timing_path objects to determine if the visual and topological common points are different. If a path is found where they differ, the timing report is printed along with pin markers indicating the common points:
pt_shell> compare_common_point [get_timing_paths -path full_clock_expanded \
? -to FF2/D]
Visual common point: U4/Z
Topological common point: U1/Z
...
Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLK)
Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLK)
Path Group: CLK
Path Type: max
Point Incr Path
--------------------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLK (in) 0.00 0.00 r
U1/I (BUFFD1) 0.00 * 0.00 r
U1/Z (BUFFD1) 2.00 * 2.00 r <-- TOPOLOGICAL
U4/I (BUFFD1) 0.00 * 2.00 r
U4/Z (BUFFD1) 2.00 * 4.00 r <-- VISUAL
U5/I (BUFFD1) 0.00 * 4.00 r
U5/Z (BUFFD1) 2.00 * 6.00 r
UMUX/A2 (OR2D1) 0.00 * 6.00 r
UMUX/Z (OR2D1) 2.00 * 8.00 r
FF1/CP (DFD1) 0.00 * 8.00 r
FF1/Q (DFD1) 2.00 * 10.00 r
FF2/D (DFD1) 0.00 * 10.00 r
data arrival time 10.00
clock CLK (rise edge) 10.00 10.00
clock source latency 0.00 10.00
CLK (in) 0.00 10.00 r
U1/I (BUFFD1) 0.00 * 10.00 r
U1/Z (BUFFD1) 1.00 * 11.00 r <-- TOPOLOGICAL
U4/I (BUFFD1) 0.00 * 11.00 r
U4/Z (BUFFD1) 1.00 * 12.00 r <-- VISUAL
FF2/CP (DFD1) 0.00 * 12.00 r
clock reconvergence pessimism 1.00 13.00
library setup time 0.00 * 13.00
data required time 13.00
--------------------------------------------------------------
data required time 13.00
data arrival time -10.00
--------------------------------------------------------------
slack (MET) 3.00
Note that the timing paths provided to the procedure must be obtained with -path full_clock_expanded so the clock paths are present for the procedure to analyze.
By default, the compare_common_point command only prints the timing reports of interest where the visual and topological common points differ, so that it can be given a large set of timing paths to process where only the interesting cases will be printed:
compare_common_point [get_timing_paths -path full_clock_expanded \
-delay min -slack_lesser_than 0 -start_end_pair]
When analyzing a particular path, if you want to have the path report always printed even when the visual and topological common points are the same, specify the -force option:
compare_common_point $this_path -force
Once a path of interest has been identified, use the second Tcl procedure make_clock_path_undesirable. When given a single timing path obtained with -path full_clock_expanded, the procedure will annotate very optimistic cell and net delays along the launch and capture paths contained in the timing_path object:
set_annotated_delay -cell -min +1000 $all_clock_min_arcs
set_annotated_delay -cell -max -1000 $all_clock_max_arcs
By setting such optimistic annotated delays, PrimeTime will prefer any other possible clock path that might exist, making the existence of any side paths easy to see:
pt_shell> make_clock_path_undesirable [get_timing_paths -to FF2/D -path full_clock_expanded]
1
pt_shell> update_timing
1
pt_shell> report_timing -to FF2/D -path full_clock_expanded -input_pins
****************************************
Report : timing
-path_type full_clock_expanded
-delay_type max
-max_paths 1
Design : test
Version: D-2009.12-SP1
Date : Tue Feb 9 05:42:18 2010
****************************************
Point Incr Path
---------------------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLK (in) 0.00 0.00 r
U1/I (BUFFD1) 0.00 * 0.00 r
U1/Z (BUFFD1) -1000.00 * -1000.00 r
U2/I (BUFFD1) 0.00 * -1000.00 r
U2/Z (BUFFD1) 2.00 * -998.00 r
U3/I (BUFFD1) 0.00 * -998.00 r
U3/Z (BUFFD1) 1.90 * -996.10 r
UMUX/A1 (OR2D1) 0.00 * -996.10 r
UMUX/Z (OR2D1) 2.00 * -994.10 r
FF1/CP (DFD1) -1000.00 * -1994.10 r
FF1/Q (DFD1) 2.00 * -1992.10 r
FF2/D (DFD1) 0.00 * -1992.10 r
data arrival time -1992.10
clock CLK (rise edge) 10.00 10.00
clock source latency 0.00 10.00
CLK (in) 0.00 10.00 r
U1/I (BUFFD1) 0.00 * 10.00 r
U1/Z (BUFFD1) 1000.00 * 1010.00 r
U4/I (BUFFD1) 1000.00 * 2010.00 r
U4/Z (BUFFD1) 1000.00 * 3010.00 r
FF2/CP (DFD1) 1000.00 * 4010.00 r
clock reconvergence pessimism 0.00 4010.00
library setup time 0.00 * 4010.00
data required time 4010.00
---------------------------------------------------------------
data required time 4010.00
data arrival time 1992.10
---------------------------------------------------------------
slack (MET) 6002.10
The -input_pins option was used so that both cell and net arcs are individually visible. If a clock path uses only the "impossible" annotated delays (as the capture path does above), we know that no other path was available. If another latency path is used, we know that at least one other alternative clock path was present.
The make_clock_path_undesirable procedure sets annotated delays along the clock path which require a timing update before the next report can be generated. It is recommended that the session be saved with save_session prior to annotating the clock path so the original timing can be restored after the side paths have been explored:
save_session ./temporary_session
make_clock_path_undesirable ...
update_timing
report_timing ...
restore_session ./temporary_session
If it is determined that the limiting side path can never happen, simply disable the connectivity through the limiting path using set_clock_sense -logical_stop_propagation to allow the CRPR algorithm to use a later common pin. By using logical clock stopping, the edge can still propagate through the pin to act as an SI aggressor, but will not be considered through that pin for clocking or CRPR purposes.
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
