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

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.

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

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.