There is the SDC command “set_clock_uncertainty” and there is the question of what clock uncertainty means.
The SDC manual states that `set_clock_uncertainty Specifies the uncertainty or skew characteristics of a single clock or between two different clocks. The timing analyzer uses this information to determine the worst possible clock arrival times for each timing check.`
Now why we need uncertainty values? For that let’s see various stages of digital design.
In synthesis, we assume the clock is ideal. There is no CTS yet, and clock pin of every sequential element is connected to the source clock without any buffering. Here the assumption is that each of these pins get clock at exactly the same time, without any variations. Since we know this isn’t going to be the case once implementation is completed, we want to specify some skew value to account for the actual delay variations between different sync points. This is not a real or measured value, but what we assume to be the worst skew once clock tree is built. The command set_clock_uncertainty lets you specify these numbers. The analyzer subtracts the setup uncertainty from the data required time for each applicable path, and adds the hold uncertainty to the data required time for each applicable path.
Let’s see an example.
set_clock_uncertainty -setup 0.5 [get_clocks SCLK] set_clock_uncertainty -hold 0.45 [get_clocks SCLK]
After specifying the above commands, setup and hold reports recalculate the clock path delay as follows. You can see that in the setup check, clock is faster due to uncertainty value, and in hold check, clock is slower.
Point Incr Path clock SCLK (rise edge) 200.00 200.00 clock network delay (ideal) 0.000 200.00 clock uncertainty -0.50 199.50
Point Incr Path clock SCLK (rise edge) 200.00 200.00 clock network delay (ideal) 0.00 200.00 clock uncertainty 0.45 200.45
Hence the set_clock_uncertainty command specifies a setup and hold margin for the synthesis tool for which the timing should be met, so as to account for actual variations in the clock.
Place & Route
Placement is done with an ideal clock and the reasons specified above are still valid for PnR tool, till placement. After CTS, you can propagate the clock and get the real skew numbers between clocks.So the uncertainty numbers as a means to specify skew is not valid anymore. However, you can still specify uncertainty as a design margin number. `set_clock_uncertainty -setup 0.5 [get_clocks SCLK]` in this context means that the worst slack without uncertainty should be > 0.5. i.e. every path in the design must meet timing with 0.5ns to spare. This is added typically to account for i)clock jitter ( The clock period is not constant. Some clock cycles are longer or shorter than others in a random fashion.See article on jitter.) and ii) on chip variation. See also set_timing_derate for another way to set the timing margins.
Pingback: Insertion Delay & set_clock_latency | VLSI Pro
Pingback: Clock Jitter | VLSI Pro
How to decide the power stripe width and spacing b/w the stripes during power planning ?
If you have access to support.cadence.com, do see the application notes there. They are pretty good. Will write an article shortly.
Hi, I believe set_clock_uncertainty adds more delay in the data path for setup and subtracts the specified in the data path for hold check.
In the timing reports they work like that. I don understand why you sub/add the uncertainty for clocks. Am I right?
Not quite. clock_uncertainty is the uncertainty of clock. So you subtract the uncertainty from clock period for setup checks, and add for hold. The resultant timing number achieved is the same if you were adding to data path for setup. But doing that is called setting a timing derate number.See http://vlsi.pro/set_timing_derate/. You can derate clock or data path. Uncertainty remains a number calculated for clock, taking into account the actual characteristics (like jitter) of the clock source.
Ma’am, I am confused still. If clock uncertainty is related to “Skew” (which is an unknown in placement stage) it should not be considered after the clocks are propagated in CTS.
If it is that Time period of clock is changed due to uncertainty value we provide, it means it is only for “Jitter” and not for skew accountability right?
Read the Place & Route part in the article above.
After CTS, clock uncertainty is used a design margin. Designers always allocate margin to designs, so that any unseen manufacturing changes doesnt affect the speed/functionality. e.g. If you close your design for 120MHz, you can be pretty certain it will work for 100MHz. So if the data sheet says 100MHz, designers still use say use 120MHz to close timing.(20MHz is specified as the uncertainty value in SDC file.)
Is there a way to provide -thr in specifying uncertainty? 2 clocks which has both half cycle and full cycle paths. how to give different uncertainty for all 4 comb?
full cycle setup
0 cycle hold
half cycle setup
half cycle hold
Why uncertainty value for setup is greater than uncertainty for hold?
Please let me know.Thanks.
Please see http://vlsi.pro/sta-setup-and-hold-time-analysis/. Remember that hold is checked at the same clock edge. So basically you are just adding the margin to the cell’s hold time. In the diagram “Timing Analysis with Ideal Clock” given in the article, you are ensuring that the data doesn’t change at thFF2+holdmargin.
However, when you specify setup uncertainty, you are constraining the path delay.You are effectively decreasing the clock period here. Setup & Hold uncertainty are thus two separate kinds of margins, and can be different.
Thank you for the wonderful article. I dont understand how the clock uncertainity affects the hold time calculation or what set_clock_uncertainty -hold 0.45 [get_clocks SCLK] signify. As we consider the same clock edges for hold. So both the launch and capture clock will have same jitter which eventually cancels out. Let me know if what I am understanding is wrong.
There is also on chip process variation to be accounted for. The process variation between the launch flop and capture flop and the relevant paths are modeled in this manner.
Thanks for the article. It helps a lot.
Can you please highlight as to how to choose the value of the Set up and Hold uncertainty itself? I am working on a design and I do not have any Uncertainty value given by the top level person who would take my digital block for integration. My design’s frequency of operation is 100 kHz. How do i know what percentage of this frequency needs to be taken as Uncertainity? Is there a formula or a thumb rule?
Please let me know.
Thumb rules exist but they are for your technology. One thing you can do is find out the jitter value of the clock source that is specified and use that as your clock uncertainty. The design team should have that value.
Otherwise, find older designs using this technology and see what are the uncertainty values used.
How do we calculate the value of skew during prects stages.
set_clock_uncertainty -setup 0.5 [get_clocks SCLK]
I mean how do we arrive at number 0.5 for SCLK ??
Jitter is one contributor
So is OCV values of your process
And add to it the margin you require.
If clock frequency is given (for example 500 MHz), How I will calculate clock uncertainty value.?
In pre cts the uncertainty equation is below
uncertainty = skew+jitter+Margin
what is Margin in that equation?what are the factors effecting margin?
does the jitter affect only at the end of time period? if yes then why cann’t it affect at the start of the time period means for the hold check ??
A good article on jitter and it’s effects on setup and hold time calculation.
I believe the deviation from ideal clock edge at two flops is important for hold check as well, even though hold is checked for the same clock cycle. The modeled value also includes clock source jitter and any deviation due to clock routing and other factors in layout.
Thank you again for your time and penning down this brilliant article. I have a doubt regarding the “set_clock_uncertainity -hold ” constraint . How will the synthesis engine use this constraint for optimizing the logic.
Thank you for the effort you put in to write this article and answer all the comments. I recently came across a constraint like this:
set_clock_uncertainty -setup -rise_from [get_clocks “clk1”] -fall_to [get_clocks “clk2”]
Could you kindly elaborate on when/why a designer should be using such a constraint and also the relationship between clk1 and clk2 (synchronous/asynchronous)
set_clock_uncertainty -setup -rise_from [get_clocks “clk1”] -fall_to [get_clocks “clk2”]
This command sets the uncertainty to paths from clk1 to clk2. Specifically, applies the uncertainty to the rising edge of the launching clock(clk1) and to the falling edge of the capture clock(clk2).
I have a question on uncertainty of generated clocks.
If I have a divided by 2 clock how does the uncertainty of the source clock affect that of the divided clock?
What my assumption is that the uncertainties will double in case of edges and duty cycle uncertainty will be same as edge uncertainty of the source clock.
This assumption falls apart when there’s a divided by 100 clock. What is the correct approach here?
My understanding is that you need to set uncertainty explicitly for the generated clocks even if you are specifying edges.
Does the uncertainty value change if our timing path is from a fast to slow clock ? If yes , how ?
No, I don’t think the value depends on that.