Clock Uncertainty/Skew

clock uncertainty skew

Hi,

Can I use below commands to apply skew in the post layout STA? will STA honour these values? because in post layout STA clock will be propagated (skew will computed depending upon the parasitics).

set_clock_uncertainty -setup 100 -clock [get_ports CLKA]
set_clock_uncertainty -hold 50 -clcok [get_ports CLKA]

Regards.

clock uncertainty

yes, you can add these constraints in post layout STA. Only clock skew will be computed by the propagated clock and for clock jitter, we can add a small delay on the uncertainity to match the real clock which will be generated from clock generation circuitry.

uncertainty propagated clock

Hi dcreddy,

Thanks for your quick reply.

Then these numbers will be taken as a jitter? If yes, then what is purpose of these below commands.

set_clock_latency -source 100 -late [get_clocks CLKA]
set_clock_latency -source 50 -early [get_clocks CLKA]

I think the above commands are used apply jitter in clock source. Correct me If I am wrong.

Regards

No, the above commands ('set_clock_latecy') emulate the clock tree NET delays (Min./Max.), and NOT jitter.

Hi Roli,

I was going through the one of the synopsys presentation on STA which I have attached.

Please will clarify me on specifying jitter is correct with set_clock_uncertainty or with set_clock_latency <jitter value> -source -late/early

Regards,

Hi arjun,

The set_clock_latency with early/late can be used for jitter margining (as shown in the doc you attached) , but I would keep this command for clock tree variations only as roli mentioned. The reason is that when you move from ideal to propagated clocks, this command goes away and you will need to account for jitter some other way. It's best to keep it consistant both pre and post CTS.

The set_clock_uncertainty will be applied the same both pre and post CTS. One issue with using this to apply jitter is that multi-cycle paths will not be accounted for properly. Say your frequency jitter can speed up your clock by 100ps, and you are timing a multi-cycle path of 4, set_clock_uncertainty will only give you 100ps of margin when you really need 400ps.

Another way to account for frequency jitter is increase your clock frequency. This fixes the multi-cycle path problem as the margin added would then the correct 400ps.

The increase frequency method works for frequency jitter but does not account for 1/2 cycle jitter. If your design has a lot of 1/2 cycle paths you can also use set_clock_uncertainty with rise/fall options to account for 1/2 cycle jitter.

Hi Shelby,

In the same doc it is mentioned that set_clock_uncertainty is used to apply skew. So I thought that when we move from Idel to propagated clocks, this command goes away and set_clock_latency can be used to account for jitter But now I understood with your explanation.

Thanks a lot to all who contributed to this discussion.


Regards,

Hi Shelby,

I got one more question on this.

As you said in your previous reply, when we move from ideal to computed (or clock propagated) set_clock_latency command goes away but I am specifying jitter with switch -source (jitter in the source clock itself) and from my understanding jitter will still be present even after clcok is propagated. please correct me if I am wrong.

Regards,

Is it possible to define "early" and "late" for he clock uncertainty?

In terms of synthesis tools, what does it mean "uncertainty 5nSec"? How is it applied on the clock? Does it mean "5ns around the clock edge"?

As for the -setup uncertainty, does it mean "clock uncertainty before the clock edge"?
As for the -hold uncertainty, does it mean "clock uncertainty before the clock edge"?

How should the negative uncertainty be defined?

Thank you!

set_clock_latency is used for clock insertion delay for network latencies , whereas set_clock_uncertainity is used for accounting the clock jitter, skew and design margin ie.. Characterization margins.

Effect of Latency and Uncertinity in Setup/hold calculations .
➢ Setup check = (Clock_edge + edge_delay - setup_uncertainty -library_setup)
➢ Hold check = (Clock_edge + edge_Delay + hold_uncertainity +library_hold )

Latency values will be taken as edge delays.

Regards, Sam