UNEXPANDABLE CLOCKS

Expandable Clocks         :

If PrimeTime or any timing engine able to derive a common period of the two clocks over a certain predefined number of cycles then those two clocks are considered as Expandable clocks.

Unexpandable Clocks  : 

In contrary to the example shown above : Two clocks are not expandable when the timing engine cannot determine their common period over certain pre-defined number of cycles. In such cases designer has to revisit the clock definitions (some timing engines consider the pre-defined number as 1000 cycles within which they verify before giving up ).

 In this case, the worst setup relationship over the 1000 cycles is used during timing analysis, but the timing engine cannot ensure this is the most pessimistic case.

This is typically the case between two clocks with an odd fractional period ratio.

 Assume two clocks : CLK1 and CLK2 generated by same primary clock:

                 CLK1  has 10.250 ns period

                 CLK2 has  13.332 ns period.

PrimeTime "expand" the periods of two clocks with different periods in order to arrive at a Least Common Multiple time where both clocks have a common rising edge/coincident edges

(e.g. the effective period gets expended in the timing-report in order to find the tightest slack path between the two clocks)

In other words : Timing Engine (PT) could not eventually come up with an interval where "beating" of the two clocks occurs in a repeating pattern. General assumption is that PT gives up after iterating over larger and larger multiples of the period to find a common repeating pattern.

unexpandable_clocks - Warns if there are sets of clocks for which periods are not expandable with respect to each other. The checking is only done for the related clock domains, such as ones where there is at least one path from one clock domain to the other. This could be because of an incorrectly defined clock period for one or more of the clocks. Another possibility is when asynchronous clocks with unexpandable periods are interacting where they should have been defined in different clock domains.

PrimeTime  "check_timing" command has option to find out such design scenarios

Man page section of  PT "check_timing" :

unexpandable_clocks :

Their rising clock edges do not realign within 1000 cycles. The timing engine uses a setup path requirement of 0.01 ns on the timing paths between the two clocks. Even if the two clocks have a known phase relationship at their clock tree root, their waveforms do not allow safe timing analysis between them. As with asynchronous clocks, the slack computation appears normally, but the value cannot be trusted. For this reason, unexpandable clocks are often assimilated to asynchronous clocks. Both clock categories must be treated the same way for constraining and clock-domain crossing circuitry.