effect of Clock Uncertainity

[verilog_always]

How different Values of Clock Uncertainity effects, in Placement stage?
Do different values of Clock Uncertainity effect any Cts/Routing results?

 

[lostinxlation]

the tool works very hard if clock uncertainty is large because it makes the timing harder to meet.

 

[srideepa]

Uncertainty refer to clock skew before Clock tree is built.

set_clock_uncertainty is the SDC command to declare the target skew for a design.

This is the constraint given to the PnR tool to build clock tree. The tool tries to honour this constraint by trying to keep skew within the said limit.

Also STA tools will use this instead of skew before CTS. It will subtract this value for setup analysis from clock path and add this up for hold analysis. Hence before CTS, as this is like a constraint, making this a bigger value will definitely affect the QoR.

Once clock network is built or in other words, set_clock_propagated is set to true, Skew is calculated from network and will be used and hence this makes no meaning for an STA tool when the input design has expanded clock.

While routing or post CTS optimization, the tool still takes into picture the target skew (for eg. the scenario of useful skew). Hence changing/tweaking will definitely impact the results.

 

[GI]

Hi,

1 - One can also use uncertainty as a further margin after CTS, e.g. to account for the PLL jitter that you don't have control over it at physical design step.

2 - As srideepa said clock uncertainty before CTS can be used to fix setup/hold timing violations, which affect QoR. As most PR tools fix timing violations below/above some thresholds, they may not touch some violations, which may eventually pop-up after CTS. Modifying clock uncertainty may be a good way of fixing these violations "before" CTS, in the expense of adding some more buffers into the design.

Best regards,
Gokhan
---

 

[shitansh]

The uncertainty can be used to model various factors that can reduce the effective clock period. These factors can be the clock jitter and any other pessimism that one may want to include for timing analysis.

set_clock_uncertainty -setup 0.2 [get_clocks CLK_CONFIG]
set_clock_uncertainty -hold 0.05 [get_clocks CLK_CONFIG]

Note that the clock uncertainty for setup effectively reduces the available clock period by the specified amount (See fig1 in attachment)

For hold checks, the clock uncertainty for hold is used as an additional timing margin that needs to be satisfied.

If there is multi-clock domain paths(Fig2. in attachment), then inter clock uncertainty can be specified as show in below commands.

#100ps is used as an uncertainty for setup checks
#50ps is used as an uncertainty for hold checks.
set_clock_uncertainty -from VIRTUAL_SYS_CLK -to SYS_CLK -hold 0.05
set_clock_uncertainty -from VIRTUAL_SYS_CLK -to SYS_CLK -setup 0.3
set_clock_uncertainty -from SYS_CLK -to CFG_CLK -hold 0.05
set_clock_uncertainty -from SYS_CLK -to CFG_CLK -setup 0.1

 

[verilog_always]

Why the values for setup and Hold are different?

 

[tsk1979]

Even I want to ask the same question.
Why is it that in most cases we see setup clock uncertainty being set more than hold uncertainty. Shouldn't both the values be same?

 

[raju3295]

generally hold will not be checked hardly as setup at least before CTS, as clock is not real, and in some implementations, we worried abt hold only after routing as the real values are available at this time only.

 

[subhash_chevella]

hello all,

After CTS also, while verifying the timing analysis we will provide different values for setup and hold uncertainty.
Generally more for setup and less for hold. Why ? What is the reason for this?

thanks and reagrds,
Subhash

 

[shitansh]

hello all,

After CTS also, while verifying the timing analysis we will provide different values for setup and hold uncertainty.
Generally more for setup and less for hold. Why ? What is the reason for this?

thanks and reagrds,
Subhash

The hold checks do not require the clock jitter to be included in the
uncertainty and thus a smaller value of clock uncertainty is generally specified
for hold.

HTH,
Shitansh Vaghela

 

[vijji.sami]

The hold checks do not require the clock jitter to be included in the
uncertainty and thus a smaller value of clock uncertainty is generally specified
for hold.

HTH,
Shitansh Vaghela

why hold checks do not require the clock jitter to be included in the
uncertainty?pls reply me soon

 

[iwpia50s]

Hold uncertainty is smaller also because you're using the fast corner for timing so the delays are shorter.

 

[venkatramanan]

bcoz we are checking hold same edge..setup ly we are checking next edge.i think so u knows jitter waveform..