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