Monday 29 March 2021

IO port delays

How to include propagated clock latency in the IO port delays through set_input_delay or set_output_delay? 

Problem : 

I have IO ports constrained using real clocks that clock both IOs and the core. I want clock tree synthesis (CTS) propagated clock latency to be included in the IO port delays asserted through set_input_delay or set_output_delay. I am using "set_global timing_io_use_clock_network_latency always", but still, the propagated core clock latency is not added to the IO delays.

Why is this happening and how can I correct this?

Solution :

  • Normally, when a clock is propagated, any asserted network latency associated with it through the set_clock_latency, SDC constraint is ignored. 
  • If you constrain the IOs with a core clock that is propagated, you should first use "set_global timing_io_use_clock_network_latency always", which will cause the asserted clock network latency set through set_clock_latency for the IOs to be used even after CTS.
  • To include the propagated clock latency (due to CTS) in the IO port delays, you should also use the -reference_pin option with the set_input_delay and set_output_delay commands. This ties the network latency used for the IO to the propagated latency of some flop's clock pin in the core.

                set_input_delay -reference_pin <ff_clock_pin_name> value pin

Example:

In the following timing report, the clock propagation time at clock pin BLK/BR2/CK is 0.345.

+-----------------------------------------------------------------------------------------------------------+

|    Instance    |   Arc             |       Cell        |    Delay      |      Arrival time   |    Required time  |

|-----------------+--------------+---------------+--------------+-------------------+----------------------|

|                      | tclk ^            |                     |                     |                  0.000 |                 -9.448 |

| CG/BC1       | A ^ -> Y ^    |     BUFX2   |          0.093  |                  0.093 |                 -9.355 |

| TC1              | A ^ -> Y ^    |     BUFX2   |           0.100 |                  0.193 |                 -9.255 |

| CG1              | B ^ -> Y ^    |  AND2X4   |           0.075 |                  0.268 |                 -9.180 |

| BLK/blkint   | A ^ -> Y ^    |     BUFX2   |          0.077 |                   0.345 |                 -9.103 |

| BLK/BR2     | CK ^             | DFFHQX1 |          0.000 |                   0.345 |                 -9.103 |

+-----------------------------------------------------------------------------------------------------------+

  • Here, you have created a clock named WAVE on the tclk port. Because the CK pin of BLK/BR2 is the leaf pin in the fanout cone of the clock source WAVE, this can be used as a reference pin to set the input delay of '0' on the ports tin and tin2 using the following command:

                set_input_delay 0 -reference_pin BLK/BR2/CK -clock WAVE {tin tin2}

  • Now, when you do report_timing on the port tin, you should be able to see the propagated clock latency of the BLK/BR2/CK pin getting accounted as the "Network Insertion Delay" component of "Beginpoint Arrival Time" at tin port.

                report_timing -from tin

Path 1: MET Setup Check with Pin TR1/BR1/CK

Endpoint: TR1/BR1/D (v) checked with leading edge of 'WAVE'

Beginpoint: tin (v) triggered by leading edge of 'WAVE'

Other End Arrival Time          0.194

- Setup                                     0.190

+ Phase Shift                          10.000

- Uncertainty                            0.123

= Required Time                      9.880

- Arrival Time                          0.544

= Slack Time                            9.336

       Clock Rise Edge                  0.000

       + Input Delay                       0.000

       + Network Insertion Delay   0.345    # The arrival time at BLK/BR2/CK pin gets accounted here

        = Beginpoint Arrival Time   0.345

+-------------------------------------------------------------------------------------------------------------+

|      Instance       |       Arc       |      Cell      |    Delay    |    Arrival time   |  Required time |

|-------------------+--------------+-------------+------------+-------------------+-------------------|

|                          | tin v            |                   |                 |                 0.345 |                9.682 |

| TU1                 | A v -> Y v   |   BUFX2   |       0.105 |                 0.451 |                9.787 |


Note: This global is "not" for virtual clocks.

Asserted network latency = latency specified using the set_clock_latency SDC constraint

Propagated clock latency = latency due to actual CTS insertion delays

No comments:

Post a Comment