7/30/2020 How Does Clock Reconvergence Pessimism Removal (CRPR) Handle Dynamically Switched Related Clocks?

Latch Based Design Search

(/s/) Cases (/s/case-list) STARs (/s/star-list) Knowledge Base (/s/knowledge) Legacy Docs Search (/s/legacy-docs-search) Feedback (/s/help)

Home > PrimeTime (80003413)

Dec 11, 2019 • Knowledge

Title
How Does Clock Reconvergence Pessimism Removal (CRPR) Handle Dynamically Switched Related Clocks?

Description
How Does Clock Reconvergence Pessimism Removal (CRPR) Handle Dynamically Switched Related Clocks?
Question:

I have a design in which a clock network switches between the original and divide-by-two version of a clock:

Figure 1: Clock Network

The clock switching circuitry is designed so that I can switch between them "on the fly" during the low portion of both clocks. This results in the following setup relationships (with clock
path latencies represented by the shaded regions):

Figure 2: Clock Paths

I model this clock configuration in PrimeTime with the following multicycle constraints:

create_clock -period 2 CLK

create_generated_clock -name CLK_div2 -source [get_ports CLK]
-divide_by 2 [get_pins UFFdiv/Q]
set_propagated_clock [all_clocks]

set_multicycle_path 2 -end -setup \

-from [get_clocks CLK_div2] -to [get_clocks CLK]
set_multicycle_path 1 -end -hold \
-from [get_clocks CLK_div2] -to [get_clocks CLK]

How does PrimeTime's clock reconvergence pessimism removal (CRPR) algorithm handle paths like this which have a launch from one clock and are then dynamically switched so the
capture is on the other clock?

Answer:

Of course, PrimeTime has no problem analyzing timing paths between different launch and capture clocks in general. The case where this becomes interesting is when the two clocks
are related, which means that both clocks share the same parent clock (as in our example above). In these cases, part of the clock path is now common and we must insure that the
CRPR behavior is correct.

By default, the CRPR algorithm in PrimeTime performs the following steps:

Compares the launch and capture clock paths

Chooses the appropriate common point for the launch and capture clock networks (using the method described in SolvNet article 017503 ())
Credits the difference in minimum/maximum arrival at this point to the path slack

This approach normalizes the minimum/maximum arrival difference at the common point from two sources:

Minimum/maximum delay differences in the timing behavior of logic gates

Minimum/maximum arrival differences caused by logic reconvergence

When clocks are muxed together, such as in our example above, the designer may have designed the circuit to operate in one of three ways:

1. The clock network is configured once on startup and the mux remains static during operation. The clock configuration is always static and the launch and capture are always on the
same clock.

2. The mux is switched during operation, but the design is held quiet until the transition completes to ensure that a path is not launched by one clock and captured by another clock.
Sometimes this involves inserting one or more functional wait cycles to ensure that no registers load a value across clock domains. Other times a more forceful approach is chosen
where the clock domain reset is asserted until the transition to the new clock completes. Since no timing path actually mixes a launch and capture across different clocks, the clock
configuration is still static within any given timing path.

3. The mux is switched during operation and the logic is specifically designed to handle paths which are launched by one clock and captured by another. This results in a clock that can
be switched dynamically between launch and capture.

https://solvnetplus.synopsys.com/s/article/How-Does-Clock-Reconvergence-Pessimism-Removal-CRPR-Handle-Dynamically-Switched-Related-… 1/4
7/30/2020 How Does Clock Reconvergence Pessimism Removal (CRPR) Handle Dynamically Switched Related Clocks?
PrimeTime cannot differentiate between these three cases by analyzing the logic, as this is something that can be determined only by the designer's intent. The first two cases are
statically switched cases, and as such, the design constraints should be suppressing paths between these clock domains with set_clock_groups or set_false_path. The third case is
the dynamically switched case where paths validly exist between the clock domains, and this requires that CRPR does not consider reconvergence between the related clocks in its clock
reconvergence pessimism calculation.

This article pertains only to dynamically switched related clocks. If the clocks are dynamically switched but not related, then no upstream portion of the clock network will require CRPR
to be applied. If the clocks are related but statically configured, then the paths between the domains would already be suppressed through clock group relationships or false paths and
the CRPR behavior never comes into play.

By default, the CRPR algorithm detects reconvergence in the clock network and removes the difference in arrival times at the common point after the reconvergence point. If we look at a
default timing report for our example circuit, we can see that CRPR is crediting the slack with the difference between the parent and divided clock latencies:

Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLK_div2)

Endpoint: UFF2 (rising edge-triggered flip-flop clocked by CLK)
Path Group: CLK
Path Type: max

Point Incr Path

---------------------------------------------------------------
clock CLK_div2 (rise edge) 0.000 0.000
clock CLK (source latency) 0.000 0.000
CLK (in) 0.000 0.000 r
U1/Z (BUFFD16) 0.047 0.047 r
UFFdiv/Q (DFD1) (gclock source) 0.173 0.220 r
Umux/Z (MUX2D1) 0.094 0.314 r
UFF1/CP (DFD1) 0.000 0.314 r
UFF1/Q (DFD1) 0.185 0.500 f
UFF2/D (DFD1) 0.000 0.500 f
data arrival time 0.500

clock CLK (rise edge) 4.000 4.000

clock source latency 0.000 4.000
CLK (in) 0.000 4.000 r
U1/Z (BUFFD16) 0.038 4.038 r
Umux/Z (MUX2D1) 0.083 4.122 r
UFF2/CP (DFD1) 0.000 4.122 r
clock reconvergence pessimism 0.193 4.314
library setup time -0.065 4.249
data required time 4.249
---------------------------------------------------------------
data required time 4.249
data arrival time -0.500
---------------------------------------------------------------
slack (MET) 3.750

We can confirm this by using the report_crpr command to see the calculation. We see that the mux output pin is shown as the common pin:

pt_shell> report_crpr -setup -from UFF1/CP -from_clock CLK_div2 \

-to UFF2/CP -to_clock CLK
****************************************
Report : CRP Calculation
Design : test
Version: A-2007.06
Date : Sun Jun 3 08:50:29 2007
****************************************

Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLK_div2)

Endpoint: UFF2 (rising edge-triggered flip-flop clocked by CLK)

Common Point: Umux/Z

Common Clock: CLK_div2
Launching edge at common point: RISING
Capturing edge at common point: RISING
CRPR threshold: 0.02

Arrival Times Early Late CRP

---------------------------------------------------------------
Rise 0.122 0.314 0.193
Fall 0.152 0.333 0.181
---------------------------------------------------------------

Selection Details
---------------------------------------------------------------
Edge Match: Match, using rise CRP
---------------------------------------------------------------
clock reconvergence pessimism 0.193

Range of accuracy of CRP in report_timing, due to value

of timing_crpr_threshold_ps: 0.173 <= CRP <= 0.193

This causes the entire difference in propagation delay to the mux output to be credited back by CRPR, which is optimistic for a dynamically switched clock.

In the PrimeTime Z-2007.06 release, a feature was introduced to configure CRPR so that reconvergence between parent/derived clocks is not considered. CRPR is still applied between
the two clocks, but only back to the last point of convergence where the two related clocks take on their unique identities. In the case above, PrimeTime would choose U1/Z as the
common point and consider only arrival differences up to that point for CRPR. We can enable this behavior with:

set timing_crpr_remove_muxed_clock_crp false

https://solvnetplus.synopsys.com/s/article/How-Does-Clock-Reconvergence-Pessimism-Removal-CRPR-Handle-Dynamically-Switched-Related-… 2/4
7/30/2020 How Does Clock Reconvergence Pessimism Removal (CRPR) Handle Dynamically Switched Related Clocks?
and now we can see that the difference in clock path latencies is left in place:

Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLK_div2)

Endpoint: UFF2 (rising edge-triggered flip-flop clocked by CLK)
Path Group: CLK
Path Type: max

Point Incr Path

---------------------------------------------------------------
clock CLK_div2 (rise edge) 0.000 0.000
clock CLK (source latency) 0.000 0.000
CLK (in) 0.000 0.000 r
U1/Z (BUFFD16) 0.047 0.047 r
UFFdiv/Q (DFD1) (gclock source) 0.173 0.220 r
Umux/Z (MUX2D1) 0.094 0.314 r
UFF1/CP (DFD1) 0.000 0.314 r
UFF1/Q (DFD1) 0.185 0.500 f
UFF2/D (DFD1) 0.000 0.500 f
data arrival time 0.500

clock CLK (rise edge) 4.000 4.000

clock source latency 0.000 4.000
CLK (in) 0.000 4.000 r
U1/Z (BUFFD16) 0.038 4.038 r
Umux/Z (MUX2D1) 0.083 4.122 r
UFF2/CP (DFD1) 0.000 4.122 r
clock reconvergence pessimism 0.009 4.130
library setup time -0.065 4.065
data required time 4.065
---------------------------------------------------------------
data required time 4.065
data arrival time -0.500
---------------------------------------------------------------
slack (MET) 3.566

Only the difference in the pre-divergence buffer U4 is removed by CRPR. The report_crpr confirms that the common pin is adjusted:

Startpoint: UFF1 (rising edge-triggered flip-flop clocked by CLK_div2)

Endpoint: UFF2 (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 0.038 0.047 0.009
Fall 0.055 0.068 0.012
---------------------------------------------------------------

Selection Details
---------------------------------------------------------------
Edge Match: Match, using rise CRP
---------------------------------------------------------------
clock reconvergence pessimism 0.009

The default value of this variable is true, which maintains the behavior of the Z-2006.12 and earlier releases where CRPR is always applied. The variable can be set to false to enable
the new behavior. For more information about this feature, see the man page for this variable or the Z-2007.06 update training material.
Although the variable name may suggest that only reconvergence through MUX cells is considered, the feature applies to reconvergence through any combinational logic. Also, note that
the related clocks do not need to be between a generated clock and its parent; two different generated clocks which are muxed together would also qualify.

Note that this article pertains only to cross-clock paths when clocks reconverge through combinational logic. It does not pertain to paths within a clock domain (with the same
launch/capture clock), even if the clock goes through a mux. Also, this article does not pertain to the case in which a path is launched and captured by different clocks with separate
clock trees, since there is no mux reconvergence and the clock reconvergence pessimism value is zero.

Workaround

Product L1
PrimeTime (/s/detail/01t1U000003IY0JQAW)

Additional Product(s)

Article Number
000004944

Last Published Date

12/11/2019, 10:39 PM

Article Record Type

https://solvnetplus.synopsys.com/s/article/How-Does-Clock-Reconvergence-Pessimism-Removal-CRPR-Handle-Dynamically-Switched-Related-… 3/4
7/30/2020 How Does Clock Reconvergence Pessimism Removal (CRPR) Handle Dynamically Switched Related Clocks?
How To

URL Name
How-Does-Clock-Reconvergence-Pessimism-Removal-CRPR-Handle-Dynamically-Switched-Related-Clocks-1576002487341

Was this article helpful? 0 0

Related Articles

How Does Clock Reconvergence Pessimism Removal (CRPR) Affect min_pulse_width Calculations? (/s/article/How-Does-Clock-Reconvergence-Pessimism-Removal-CRPR-Af
3.84K
fect-min-pulse-width-Calculations-1576002482580)

Difference between clock_tree_pulse_width and sequential_clock_pulse_width? (/s/article/Difference-between-clock-tree-pulse-width-and-sequential-clock-pulse-width-1576

1.51K
091231041)

Minimum Pulse Width Calculation Based on Clock Pin Transition (/s/article/Minimum-Pulse-Width-Calculation-Based-on-Clock-Pin-Transition-1576092609899) 1.93K

How can I get Details of the Clock Network Elements That Cause Pulse Width Violations? (/s/article/How-can-I-get-Details-of-the-Clock-Network-Elements-That-Cause-Pulse-W
1.6K
idth-Violations-1576091148356)

Constraining and Analyzing a Design for Minimum Pulse Width and Minimum Period Checks in PrimeTime (/s/article/Constraining-and-Analyzing-a-Design-for-Minimum-Pulse
9.41K
-Width-and-Minimum-Period-Checks-in-PrimeTime-1576008925611)

Related Files (0)

Article Comments (0) (/s/relatedlist/ka01U000001djgUQAQ/Article_Comments__r) New

Saved Articles (0) (/s/relatedlist/ka01U000001djgUQAQ/Saved_Articles__r) New

https://solvnetplus.synopsys.com/s/article/How-Does-Clock-Reconvergence-Pessimism-Removal-CRPR-Handle-Dynamically-Switched-Related-… 4/4