set_clock_uncertainty

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.

Synthesis

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.

Setup Analysis:

  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

Hold Analysis:

  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.

28 comments on “set_clock_uncertainty

  1. Pingback: Insertion Delay & set_clock_latency | VLSI Pro

  2. Pingback: Clock Jitter | VLSI Pro

  3. Sini

    Hi Manjesh,

    If you have access to support.cadence.com, do see the application notes there. They are pretty good. Will write an article shortly.

    Sini

    Reply
  4. Shyam Krish

    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?

    Reply
    1. Sini Mukundan Post author

      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.

      Reply
  5. Shyam Krish

    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?

    Reply
  6. Sini

    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.)

    Reply
  7. Ankit

    HI Sini,

    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

    Reply
    1. Sini Mukundan Post author

      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.

      Reply
  8. Akshay

    Hi Sini,

    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.

    Reply
    1. Sini

      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.

      Reply
  9. Anjan

    Hi Sini,

    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.

    Thanks,
    Anjan

    Reply
    1. Sini

      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.

      Reply
  10. Navaneeth

    Hi Sini,
    If clock frequency is given (for example 500 MHz), How I will calculate clock uncertainty value.?

    Reply
  11. Naveen Reddy

    hi,
    In pre cts the uncertainty equation is below
    uncertainty = skew+jitter+Margin
    what is Margin in that equation?what are the factors effecting margin?

    Reply
  12. debaprasad daxiniray

    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 ??

    Reply
  13. Vivek

    Hello Srini,

    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,
    Vivek

    Reply
  14. pramod

    Hi Sini,

    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)

    Reply
    1. Sini Mukundan Post author

      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).

      Reply
  15. Hari

    Hi Sini,

    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?

    Thanks

    Reply
    1. Sini Mukundan Post author

      My understanding is that you need to set uncertainty explicitly for the generated clocks even if you are specifying edges.

      Reply
  16. jeff

    Does the uncertainty value change if our timing path is from  a fast to slow clock ? If yes , how ?

    Reply

Leave a Reply to Vivek Cancel reply

Your email address will not be published. Required fields are marked *