Clock Uncertainty

You can model the expected uncertainty (skew) for a prelayout design with setup or hold and rise or fall uncertainty values.

1. PrimeTime subtracts a setup uncertainty value from the data required time when it checks setup time (maximum paths).
2. PrimeTime adds a hold uncertainty value to the data required time when it checks the hold time (minimum paths).

 

If you specify a single uncertainty value, PrimeTime uses it for both setup checks and hold checks.

 

You can specify the uncertainty or skew characteristics of clocks by using the set_clock_uncertainty command. The command specifies the amount of time variation in successive edges of a clock or between edges of different clocks. It captures the actual or predicted clock uncertainty.  

 

You can specify simple clock uncertainty or interclock uncertainty. Simple uncertainty is the variation in the generation of successive edges of a clock with respect to the exact, nominal times. You specify one or more objects, which can be clocks, ports, or pins. The uncertainty value applies to all capturing latches clocked by the specified clock or whose clock pins are in the fanout of the specified ports or pins.

 

Interclock uncertainty is more specific and flexible, supporting different uncertainties between  clock domains. It is the variation in skew between edges of different clocks.

You specify a “from” clock using the -from, -rise_from, or -fall_from option and a “to” clock the -to, -rise_to, or -fall_to option. The interclock uncertainty value applies to paths that start at the “from” clock and end at the “to” clock. Interclock uncertainty is relevant when the source and destination registers are clocked by different clocks.

You can define uncertainty similarly between two clock pins driven from the same clock, or you can define it as an interclock uncertainty between two registers with different clocks, as shown in Figure

 

 Example of Interclock Uncertainty

 

  

When performing a setup or hold check, PrimeTime adjusts the timing check according to the worst possible difference in clock edge times. For example, for a setup check, it subtracts the  uncertainty value from the data required time, thus requiring the data to arrive sooner by that amount, to account for a late launch and an early capture with the worst clock skew. 

 

When a path has both simple clock uncertainty and interclock uncertainty, the interclock uncertainty value is used, for example  

pt_shell> set_clock_uncertainty 5 [get_clocks CLKA]

 

pt_shell> set_clock_uncertainty 2 -from [get_clocks CLKB] \

 

-to [get_clocks CLKA]

 

When the path is from CLKB to CLKA, the interclock uncertainty value 2 is used.

 

The following commands specify interclock uncertainty for all possible interactions of clock

 

domains. If you have paths from CLKA to CLKB, and CLKB to CLKA, you must specify the

 

uncertainty for both directions, even if the value is the same. For example,

 

pt_shell> set_clock_uncertainty 2 -from [get_clocks CLKA] \

 

-to [get_clocks CLKB]

 

pt_shell> set_clock_uncertainty 2 -from [get_clocks CLKB] \

 

-to [get_clocks CLKA]

 

To set simple clock uncertainty (setup and hold) for all paths leading to endpoints clocked by  

U1/FF*/CP, enter

 

pt_shell> set_clock_uncertainty 0.45 [get_pins U1/FF*/CP]

 

To set a simple setup uncertainty of 0.21 and a hold uncertainty of 0.33 for all paths leading to endpoints clocked by CLK1, enter

 

pt_shell> set_clock_uncertainty -setup 0.21 [get_clocks CLK1]

 

pt_shell> set_clock_uncertainty -hold 0.33 [get_clocks CLK1]

 

To remove clock uncertainty information from clocks, ports, pins, or cells, or between specified clocks, use the remove_clock_uncertainty command removes uncertainty.

 

Reference: https://solvnet.synopsys.com/