Recovery and Removal Checks

Recovery and removal analysis are done on asynchronous signals like resets. These specify the requirement of these signals with respect to clock.Recovery Time is the minimum required time to the next active clock edge the after the reset (or the signal under analysis) is released. Similarly, Removal Time is the minimum required time after the clock edge after which reset can be released. You are trying to make sure that the reset removal is not occurring for different flops for different clock edges, thereby creating functional/metastability issues.
For the clock edges A & B, Tr is the recovery time, and Tm is the removal time. RESET cannot be released within these intervals.

Here, reset_n is applied in the beginning and after edge A, it is released. However, the clock edge B comes too soon after the reset_n release. (The release is within the Tr of edge B). Hence this is a case of recovery violation. Similarly, if the reset_n was released within the Tm time range, it would be a removal violation. You can see that recovery time is like the setup check, in that this is the time the asynchronous input should be stable before the arrival of the clock. Similarly removal is the equivalent of hold check, in that the asynchronous input should be held after the clock edge.

Let let us see how to read the timing reports. Given below is an example schematic. Look up the drill from Setup & Hold .


Recovery Slack = Data Required Time – Data Arrival Time

Data Arrival Time = Clock Network Delay to FF1 + Combination path delay to CLR of FF2.
Data Required Time = Clock period + Clock Network Delay to FF2/CP – Tr of FF2.

For ideal clock, Tr is the time before the next clock edge the CLR input should be stable. This library removal time for CLK-CLR arc will be given in the .lib.

  Startpoint: control/currentstate_reg1
               (rising edge-triggered flip-flop clocked by sclk)
  Endpoint: shift_reg_reg8
               (recovery check against rising-edge clock sclk')
  Path Group: **async_default**
  Path Type: max

  Point                       Fanout    Cap      Trans       Incr       Path
  clock sclk (rise edge)                                   0.0000     0.0000
  clock network delay (propagated)                         5.4068     5.4068
  control/currentstate_reg1/CP (SDFFCQX2)       1.1966     0.0000     5.4068 r
  control/currentstate_reg1/Q (SDFFCQX2)        1.2736     1.2589 &   6.6656 r
  control/currentstate[1] (net)   6   0.0933 
  control/U5/Y (NAND2X1)                        0.8768     0.4963 &   7.1619 f
  control/n37 (net)               2   0.0529 
  control/U31/Y (AOI22X2)                       2.0933     1.2677 &   8.4296 r
  control/testmode (net)          8   0.2093 
  control/testmode (control_t1)                 0.0000     0.0000 &   8.4296 r
  testmode_i (net) 
  rst/IN2 (ck_rst_t1)                           0.0000     0.0000 &   8.4296 r
  rst/IN2 (net) 
  rst/U8/Y (AOI21X1)                            1.2645     1.0233 &   9.4529 f
  rst/n3 (net)                    1   0.0457 
  rst/U9/Y (AOI21X1)                            0.7661     0.5541 &  10.0070 r
  rst/nreset_spc2 (net)           1   0.0136 
  rst/nreset_spc2 (ck_rst_t1)                   0.0000     0.0000 &  10.0070 r
  nreset_spc2 (net) 
  U77_ICC_place/Y (BUFX3)                       3.0074     1.8044 &  11.8114 r
  n87 (net)                       15   0.4463 
  U78_ICC_place/Y (INVX3)                       1.9985     1.3313 &  13.1427 f
  n88 (net)                       14   0.3073 
  nreset (spc2_t1)                              0.0000     0.0000 &  13.1427 f
  nreset (net) 
  U72/Y (AOI21X1)                               1.8788     1.1913 &  14.3340 r
  n194 (net)                       4   0.0690 
  U216/Y (AND2X2)                               1.7628     1.1913 &  15.5253 r
  n120 (net)                       5   0.1476 
  U6_ICC_cts/Y (INVX3)                          1.4885     1.0081 &  16.5334 f
  n461 (net)                      13   0.2593 
  shift_reg_reg8/CLR (DFFCX2)                   1.4873     0.0011 &  16.5345 f
  data arrival time                                                  16.5345

  clock sclk' (rise edge)                                 30.0000    30.0000
  clock network delay (propagated)                         2.8310    32.8310
  shift_reg_reg8/CP (DFFCX2)                              32.8310 r
  library recovery time                                   -0.7776    32.0533
  data required time                                                 32.0533
  data required time                                                 32.0533
  data arrival time                                                 -16.5345
  slack (MET)                                                        15.5188

Removal check is similar to the hold check explained here. You are checking this at the same clock edge, if the path is between two flip flops.

Removal Slack = Data Arrival Time – Data Required Time

Data Arrival Time = Clock Network Delay to FF1/CP + Combination path delay from FF1/Q to FF2/CLR
Data Required Time = Clock Network Delay to FF2/CP + Tm of FF2
The library requirements will be available in the .lib file. Again, assuming ideal clock, the CLR input should not reach the FF2/CLR at least before the library removal requirement.

  Startpoint: reset_reg
               (rising edge-triggered flip-flop clocked by clk_c)
  Endpoint: trim_refresh_en_reg
               (removal check against rising-edge clock clk_c)
  Path Group: **async_default**
  Path Type: min

  Point                       Fanout    Cap      Trans       Incr       Path
  clock clk_c (rise edge)                                  0.0000     0.0000
  clock network delay (propagated)                         3.8572     3.8572
  reset_reg/CP (SDFFPQX2)
                                                0.9145     0.0000     3.8572 r
  reset_reg/Q (SDFFPQX2)
                                                0.4055     1.0647 &   4.9219 f
  reset_oc_sync2 (net)
                                 2   0.0235 
  U27/Y (MUX2X2_QQC1)                           1.3584     1.3341 &   6.2560 f
  reset_oc (net)                6   0.1814 
  reset_oc (ck_rst_t1)                          0.0000     0.0000 &   6.2560 f
  reset_oc (net) 
  IN1 (ck_rst_t1)                               0.0000     0.0000 &   6.2560 f
  IN1 (net) 
  trim_refresh_en_reg/CLR (SDFFCX2)             1.3584     0.0034 &   6.2594 f
  data arrival time                                                   6.2594

  clock clk_c (rise edge)                                  0.0000     0.0000
  clock network delay (propagated)                         3.9515     3.9515
  trim_refresh_en_reg/CP (SDFFCX2)                         3.9515 r
  library removal time                                     0.0580     4.0095
  data required time                                                  4.0095
  data required time                                                  4.0095
  data arrival time                                                  -6.2594
  slack (MET)                                                         2.2499

11 comments on “Recovery and Removal Checks

  1. DMohanty

    In my opinion during recovery and removal check the reference signal is asynchronous signal,correct me if i am wrong.

  2. balu

    Hi, How do you make sure that the reset pin will not fall in that period, because it might trigger at anytime?..(like the reset pin in any device)

  3. abeaut


    Thanks for the post. It doesn’t make sense from your explanation and the timing report. The checks are for synchronous signals and not for asynchronous ones.

    You will violate setup/hold times for asynchronous signals, that is the reason you need synchronizers.

  4. Dhivakar

    is there any command for fixing hold violation meanwhile no take any action on set violation(in encounter tool)

  5. Suresh

    Thanks for your examples.
    What would be the problem if we model recovery checks are setup checks in .lib ?
    Does it create problem during STA?


Leave a Reply

Your email address will not be published. Required fields are marked *