clock network delay difference in primetime with OCV

[malisvce]

Hello
I tried doing primetime analysis with single wc library.
The clock network delay I see in with operating condition set to single is 1.15 ns.

However, for the same path, if I enable on chip variation, I am seeing a clock network delay of 1.01 ns.
further in on chip variation mode, if I do

report_timing -from flop1/CP ,
the clock networkdelay of launch flop : flop1 is 1.15 ns.

report_timing -to flop1/D
the clock network delay is 1.01 ns.

Do you all understand the differences?
What is the correct way to on chip variation analysis with single library.

Thanks,
Mali

 

[artmalik]

The OCV margin is implemented through simulations depending on the depth of clock tree. You should check where the OCV margins are, it is usually generated outside the normal .lib/.db characterization. Please check the OCV margin tables that you are using. It might be embedded in the files that you upload during the primetime runs.

 

[malisvce]

The OCV margin is implemented through simulations depending on the depth of clock tree. You should check where the OCV margins are, it is usually generated outside the normal .lib/.db characterization. Please check the OCV margin tables that you are using. It might be embedded in the files that you upload during the primetime runs.

@ artmalik: thanks for the response.
I am uploading the netlist, WC library .db file and the max corner spef file. Is there any chance its coming from these, I dont think so, but checking just in case. or is the PT tool calculating it internally?

 

[artmalik]

https://www.synopsys.com/Tools/Implementation/SignOff/CapsuleModule/PrimeTime_AdvancedOCV_WP.pdf
it is possible that it is coming as a result of some default setting. Please see this online documentation which explains the OCV margin settings.

 

[malisvce]

Yes, the documents explains the aocv strategy.
Do anyone have any info if this is enabled by default with operating conditions set to on chip variation?
I am seeing different derating factor for capture clock network insertion delay based on clock path length etc, so it looks like aocv.
But clear information will help to understand and set any further derating we have to apply for timing closure.

 

[malisvce]

The delay difference in ocv mode was due to slew degradation. the tool degrades slew only in max paths and not in min paths.

there is a variable to remove this from happening.....rc_degrade_min_slew_when_rd_less_than_rnet

thanks artmalik for ur responses.

 

[D.A.(Tony)Stewart]

TQ models On-Chip Variation(OCV) shows setup and hold times.

If you need more detail, change report_timing -detail to full_path. If you want even more than that, add "-show_routing" to the command

 

[verymiss]

This is normal.we know you have set two deraring factors, for lanuch path, the factor is 1, and for capture path is 0.878(1.01/1.15). so when you do report_timing -from flop1/CP, the reg is in the lanuch path,and its delay has no change.then, when you report_timing -to flop1/D ,the reg is in capture path, its delay has the factor 0.878.