setting clock setup&hold uncertainity

Hi guys,

I have been searching about the clock uncertainty and what I got is that it represents the maximum skew @ clock inputs of different flops for a given clock tree. If this understanding is correct kindly confirm.

My question here is, what are the basis that I should use to be able to set the clock uncertainty in synthesis flow ? And if I leave it unset, what would the tool assume ?
Sometimes I have seen that the clock setup&hold uncertainties are not equal !! What does this mean ?
Based on my understanding above, there is a maximum value of positive or negative skew around the ideal clock edge, what is the meaning of setup&hold terms in this context ?


Thanks,
Best Regards,

https://www.edn.com/design/analog/4371393/Understanding-the-basics-of-setup-and-hold-time

Memory cells, FF's or any edge sensitive logic must have a setup and hold time must have data stable for this amount when the worst case clock skew edge occurs. This is a standard requirement for synchronous logic.


Otherwise for asynch logic, race conditions require all skew between data and clock to avoid races or missing pulses or glitches.

Thanks for your reply.

But I'm aware of the setup & hold basics. I'm asking about the setup & hold clock uncertainty not the setup & hold for the flops. I can not relate them as the concept of clock uncertainty represents the skew between clock edges @ flop clock inputs. Is there any reason to have a setup uncertainty different from hold uncertainty ?
Or should I set them equal ?

In case I do not constrain the clock uncertainty what will the tool do ?

The setup uncertainty will usually not be equal to the hold uncertainty. I am not aware of the reason apart from saying that it must be due to device physics.
In case you don't specify these uncertainties the tool does a very optimistic timing analysis thereby giving you false hopes.

Setup uncertainty is used to specify the expected maximum variance in the clock tree under worst-case conditions. It is only specified prior to clock tree synthesis and back-annotation. (Once the clock tree is generated, the actual uncertainty can be calculated by the static analysis tool)

The reason for setup and hold uncertainty is that static timing analyzers use the clock period and 'worst case' numbers for finding setup violations. For hold violations, a static timing analyzer uses 'best case' numbers, and for single-clock circuits, the clock period doesn't matter for determining hold time violations.

Suppose we have the circuit in the attached txt file: View attachment ckt.txt
For setup uncertainty, suppose under worst-case conditions (temperature, voltage, process variations)

delay_u1=1.0ns
delay_u2=1.0ns
delay_u3=0.5ns
delay_ff = 0ns
setup_ff=hold_ff=0.1ns

This means that data will "launch" from ff1 at t=2.0 ns, and every 10ns thereafter. (22ns, 32ns, etc)
Data will be "captured" at ff2 at t=1.5 ns, and every 10ns thereafter (11.5ns, 21.5ns, etc).

So, even though there's a 10ns clock *period*, in general there's a 0.5ns variance in the arrival time of the clock edge. So we need to tell the synthesis tool we expect 'uncertainty' in the clock arrival time under worst-case conditions of 0.5 ns:

create_clock -period 10 [get_ports CLK]
set_clock_uncertainty -setup 0.5 [get_clocks CLK]

This tells the static analysis tool that for *any* flop-to-flop path, the maximum time between two flip-flops that can be used for setup calculations is (10-0.5-0.1)=9.4ns

For hold uncertainty, suppose under best-case conditions (temperature, voltage, process variations)

delay_u1=0.0ns
delay_u2=0.0ns
delay_u3=0.2ns

So, we need to tell the static analysis tool we expect an 0.2ns variation in our clock tree under best-case conditions, via
set_clock_uncertainty -hold 0.2 [get_clocks CLK]

This means that data will "launch" from ff1 at t=0.0 ns, but data will not be 'launched' from ff2 until t=0.2. AND, ff2 has a hold time of 0.1ns, so new data can't appear at ff2 until t=0.3. So unless the best-case delay of the 'logic' is 0.3ns, the static analysis tool will flag a violation [a synthesis tool may insert buffers in the logic to increase the delay of the logic, which could paradoxically then cause a setup violation]

Hope this helps