Generate clocks and their clock uncertainties

create_clock -name clk_osc \
             -period 100 \
             u_osc/out

create_generated_clock -name clk_gen_osc \
                       -divide_by 2 \
                       -source [get_pins u_osc/out] \
                        u_clk_gen/out

# edge-to-edge
set_clock_uncertainty -setup [expr 100*1/100] -rise_from clk_osc -rise_to clk_osc 
set_clock_uncertainty -setup [expr 100*1/100] -fall_from clk_osc -fall_to clk_osc 

# duty cycle
set_clock_uncertainty -setup [expr 100*10/100] -rise_from clk_osc -fall_to clk_osc 
set_clock_uncertainty -setup [expr 100*10/100] -fall_from clk_osc -rise_to clk_osc

1. Will it be same as clk_osc?
2. Will the edge-to-edge uncertainty of clk_osc become duty-uncertainty of clk_gen_osc, and edge-to-edge uncertainty of clk_gen_osc twice the edge-to-edge uncertainty of clk_osc ?
3. Will the uncertainty depend on whether the generated clock is from a flop based divider or pulse dropped version through a clock gate ?

KlausST said:

Hi,

not easy to answer.

lets say the input clock rising edge has an uncertainty of 1%, and you use this edge for the divider..
* then the input clock duty cycle plays no role. But this is theortecitally only

Click to expand...

KlausST said:

now imagine a clock divider "/n".
only every n-th input rising edge will cause a edge at the output signal.
--> Then I´d say 1% input clock uncertainty will become 1%/n of output clock uncertainty.
--> and (2*1%)/n in duty cycle uncrertainty.

But in detail it depends on the frequency spectrum of the input clock jitter.
Since the uncertainty is integrated over n cycles
--> a low frequency jitter will be almost added up to the input clock uncertainty of 1% (which means a change in frequency)
--> a high frequency clock jitter may be almost cancelled out.

Klaus

Click to expand...

1. A low frequency jitter of 1% might get transferred as n*1% jitter on a divide-by-n generated clock. If this 'n' is big, say 100, then the jitter will really get bad over time for the generated clock?
2. A high frequency jitter of 1% means it'll not be n*1% for the generated clock since it disappears over time. I guess to put a value to 'n' here will be case dependent.

Can you explain why it is only theoretically correct ?

Click to expand...

A low frequency jitter of 1% might get transferred as n*1% jitter on a divide-by-n generated clock. If this 'n' is big, say 100, then the jitter will really get bad over time for the generated clock?

Click to expand...