The differences between -async , physically_exclusive , logically_exclusive for command

set_clock_groups during crosstalk analysis are the following:

PHYSICALLY_EXCLUSIVE:

Means Timing paths between these clock domains are false, but only one clock can exist in the design at
the same time. ETS/Tempus will filter out the SI interactions of nets/paths between these groups.
To phrase it differently, if the clocks are exclusive, then there should be no SI victim/aggressor
interaction at all between nets clocked by physically excluded clocks.

ASYNCHRONOUS

If two clocks are asynchronous, it means that they don't have any phase relationship among them at all.
So instead of using definite timing windows based on arrival times/skew etc, the tool will use infinite
timing windows when calculating aggressors and victims, therefore you will see maximum SI impact.

LOGICALLY_EXCLUSIVE

Logically exclusive means the timing paths between these clock domains are false, but both clocks can
exist in the design at the same time, so SI interactions between paths in these domains should still be
considered. However crosstalk analysis will be done with regular timing windows based on arrival
times/skew etc.

Question:

I have some clock logic that selects among a clock, its divide-by-2 version, and its divide-by-4
version:

Figure 1: Clock Logic

The divide-by-2 and divide-by-4 clocks are generated using parallel state machines to avoid the
latency penalty and duty cycle variations of cascaded clock dividers. The MUX is statically
switched and does not switch between the clocks dynamically during device operation.

What is the proper way to constrain this clock structure in PrimeTime?

Answer:
Although the clock logic is simple, the correct clock specification might not be obvious. Let's
walk through the problem and explore how these clocks should be specified.

Multiple Generated Clocks Defined on a Pin

Let's start out with a basic attempt at specifying these clocks:

create_clock -period 10 CLK

create_generated_clock -name CLKdiv2 -divide_by 2 UMUX/Y -source FFdiv2/CK
-master CLK -add
create_generated_clock -name CLKdiv4 -divide_by 4 UMUX/Y -source FFdiv4/CK
-master CLK -add
set_clock_groups -physically_exclusive -group {CLK} -group {CLKdiv2} -group
{CLKdiv4}

First, we create a primary clock at the input port. Then, we create two generated clocks at the
MUX output, one for each divider. We use the -master and -add options to allow multiple
generated clocks to be created on the same pin. We specify the -source pin for CLKdiv2_mux
as FFdiv2/CK, and the -source pin for CLKdiv4_mux as FFdiv4/CK. Finally, we mark all three
clocks as physically exclusive as only one clock at a time could be present at the output of the
MUX.

With these commands in place, let's generate the timing reports and analyze the results:

pt_shell> report_timing -path full_clock_timing

...omitted...

Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLKdiv2)

Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLKdiv2)
Path Group: CLKdiv2
Path Type: max

Point Incr Path

---------------------------------------------------------------
clock CLKdiv2 (rise edge) 0.00 0.00
clock CLK (source latency) 0.00 0.00
CLK (in) 0.00 0.00 r
FFdiv4/CK (DFF) 0.00 * 0.00 r
FFdiv4/Q (DFF) 1.10 * 1.10 r
UMUX/C (MUX3) 0.00 * 1.10 r
UMUX/Y (MUX3) (gclock source) 1.00 * 2.10 r
FF1/CK (DFF) 0.00 * 2.10 r
FF1/Q (DFF) 1.00 * 3.10 r
FF2/D (DFF) 0.00 * 3.10 r
data arrival time 3.10

clock CLKdiv2 (rise edge) 20.00 20.00

clock CLK (source latency) 0.00 20.00
CLK (in) 0.00 20.00 r
UMUX/A (MUX3) 0.00 * 20.00 r
UMUX/Y (MUX3) (gclock source) 1.00 * 21.00 r
FF2/CK (DFF) 0.00 * 21.00 r
 clock reconvergence pessimism 1.10 22.10
library setup time 0.00 22.10
data required time 22.10
---------------------------------------------------------------
data required time 22.10
data arrival time -3.10
---------------------------------------------------------------
slack (MET) 19.00

Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLKdiv4)

Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLKdiv4)
Path Group: CLKdiv4
Path Type: max

Point Incr Path

---------------------------------------------------------------
clock CLKdiv4 (rise edge) 0.00 0.00
clock CLK (source latency) 0.00 0.00
CLK (in) 0.00 0.00 r
FFdiv4/CK (DFF) 0.00 * 0.00 r
FFdiv4/Q (DFF) 1.10 * 1.10 r
UMUX/C (MUX3) 0.00 * 1.10 r
UMUX/Y (MUX3) (gclock source) 1.00 * 2.10 r
FF1/CK (DFF) 0.00 * 2.10 r
FF1/Q (DFF) 1.00 * 3.10 r
FF2/D (DFF) 0.00 * 3.10 r
data arrival time 3.10

clock CLKdiv4 (rise edge) 40.00 40.00

clock CLK (source latency) 0.00 40.00
CLK (in) 0.00 40.00 r
UMUX/A (MUX3) 0.00 * 40.00 r
UMUX/Y (MUX3) (gclock source) 1.00 * 41.00 r
FF2/CK (DFF) 0.00 * 41.00 r
clock reconvergence pessimism 1.10 42.10
library setup time 0.00 42.10
data required time 42.10
---------------------------------------------------------------
data required time 42.10
data arrival time -3.10
---------------------------------------------------------------
slack (MET) 39.00

The most obvious issue here is that there are timing reports for the divided clock domains, but
there is no report for the parent clock domain CLK. This is due to the following behavior of
generated clocks:

When a generated clock is created at a pin, all other clocks arriving at that pin are blocked
unless they too have generated clock versions created at that pin.

In other words, clock CLK gets blocked at UMUX/Y unless we also create a generated clock
version of clock CLK at UMUX/Y (and adjust the set_clock_groups command accordingly):
create_clock -period 10 CLK
create_generated_clock -name CLK_mux -combinational UMUX/Y -source CLK -master
CLK -add
create_generated_clock -name CLKdiv2 -divide_by 2 UMUX/Y -source FFdiv2/CK
-master CLK -add
create_generated_clock -name CLKdiv4 -divide_by 4 UMUX/Y -source FFdiv4/CK
-master CLK -add
set_clock_groups -physically_exclusive -group {CLK_mux} -group {CLKdiv2}
-group {CLKdiv4}

This solves the missing CLK path issue.

The Clock Source Latency Path Issue

However, if we take a closer look at the clock latency paths above, we notice a more subtle
problem - for both divided clocks, the launch paths go through UMUX/C (the divide-by-4 state
machine flip-flop) and the capture paths go through UMUX/A (the undivided clock path). This
behavior is due to an important aspect of the -source option of the create_generated_clock
command:

The -source option of the create_generated_clock command determines the identity of

the master clock, and the sense (non-inverted or inverted) of that master clock. It does not
steer the source latency path. Once the master clock's identity and sense are determined, all
possible paths back to that clock's source are considered for the source latency path.

In other words, although we have specified "-source FFdiv2/CK" for CLKdiv2_mux, it does
not force the source latency path to go through that pin. Instead, PrimeTime observes that the
non-inverted sense of CLK is present at pin FFdiv2/CK. Then, the tool searches for all possible
non-inverting paths back to source of clock CLK, which is the input port named CLK. Since
these are setup paths, the slowest non-inverting path back to input port CLK is the path through
FFdiv4, and the fastest non-inverting path is through the undivided path.

The best way to steer the source latency paths for generated clocks is to create the generated
clock directly at the point of the clock's transformation. In this case, the divided clocks should be
created at the Q pin of each divider flip-flop. This ensures that the generated clocks can only
look at source latency paths which can reach that divider's clock pin:

create_clock -period 10 CLK

create_generated_clock -name CLKdiv2 -divide_by 2 FFdiv2/Q -source FFdiv2/CK
create_generated_clock -name CLKdiv4 -divide_by 4 FFdiv4/Q -source FFdiv4/CK
set_clock_groups -physically_exclusive -group {CLK} -group {CLKdiv2} -group
{CLKdiv4}

By creating each generated clock on different pins, the -master and -add options are no longer
necessary. Also, the undivided clock now simply propagates through the MUX to converge with
the divided clocks at the MUX output. This results in the following correct timing reports:

Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLK)

Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLK)
Path Group: CLK
Path Type: max

Point Incr Path

---------------------------------------------------------------
clock CLK (rise edge) 0.00 0.00
clock source latency 0.00 0.00
CLK (in) 0.00 0.00 r
UMUX/A (MUX3) 0.00 * 0.00 r
UMUX/Y (MUX3) 1.00 * 1.00 r
FF1/CK (DFF) 0.00 * 1.00 r
FF1/Q (DFF) 1.00 * 2.00 r
FF2/D (DFF) 0.00 * 2.00 r
data arrival time 2.00

clock CLK (rise edge) 10.00 10.00

clock source latency 0.00 10.00
CLK (in) 0.00 10.00 r
UMUX/A (MUX3) 0.00 * 10.00 r
UMUX/Y (MUX3) 1.00 * 11.00 r
FF2/CK (DFF) 0.00 * 11.00 r
clock reconvergence pessimism 0.00 11.00
library setup time 0.00 11.00
data required time 11.00
---------------------------------------------------------------
data required time 11.00
data arrival time -2.00
---------------------------------------------------------------
slack (MET) 9.00

Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLKdiv2)

Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLKdiv2)
Path Group: CLKdiv2
Path Type: max

Point Incr Path

---------------------------------------------------------------
clock CLKdiv2 (rise edge) 0.00 0.00
clock CLK (source latency) 0.00 0.00
CLK (in) 0.00 0.00 r
FFdiv2/CK (DFF) 0.00 * 0.00 r
FFdiv2/Q (DFF) (gclock source) 0.90 * 0.90 r
UMUX/B (MUX3) 0.00 * 0.90 r
UMUX/Y (MUX3) 1.00 * 1.90 r
FF1/CK (DFF) 0.00 * 1.90 r
FF1/Q (DFF) 1.00 * 2.90 r
FF2/D (DFF) 0.00 * 2.90 r
data arrival time 2.90

clock CLKdiv2 (rise edge) 20.00 20.00

clock CLK (source latency) 0.00 20.00
CLK (in) 0.00 20.00 r
FFdiv2/CK (DFF) 0.00 * 20.00 r
FFdiv2/Q (DFF) (gclock source) 0.90 * 20.90 r
UMUX/B (MUX3) 0.00 * 20.90 r
UMUX/Y (MUX3) 1.00 * 21.90 r
 FF2/CK (DFF) 0.00 * 21.90 r
clock reconvergence pessimism 0.00 21.90
library setup time 0.00 21.90
data required time 21.90
---------------------------------------------------------------
data required time 21.90
data arrival time -2.90
---------------------------------------------------------------
slack (MET) 19.00

Startpoint: FF1 (rising edge-triggered flip-flop clocked by CLKdiv4)

Endpoint: FF2 (rising edge-triggered flip-flop clocked by CLKdiv4)
Path Group: CLKdiv4
Path Type: max

Point Incr Path

---------------------------------------------------------------
clock CLKdiv4 (rise edge) 0.00 0.00
clock CLK (source latency) 0.00 0.00
CLK (in) 0.00 0.00 r
FFdiv4/CK (DFF) 0.00 * 0.00 r
FFdiv4/Q (DFF) (gclock source) 1.10 * 1.10 r
UMUX/C (MUX3) 0.00 * 1.10 r
UMUX/Y (MUX3) 1.00 * 2.10 r
FF1/CK (DFF) 0.00 * 2.10 r
FF1/Q (DFF) 1.00 * 3.10 r
FF2/D (DFF) 0.00 * 3.10 r
data arrival time 3.10

clock CLKdiv4 (rise edge) 40.00 40.00

clock CLK (source latency) 0.00 40.00
CLK (in) 0.00 40.00 r
FFdiv4/CK (DFF) 0.00 * 40.00 r
FFdiv4/Q (DFF) (gclock source) 1.10 * 41.10 r
UMUX/C (MUX3) 0.00 * 41.10 r
UMUX/Y (MUX3) 1.00 * 42.10 r
FF2/CK (DFF) 0.00 * 42.10 r
clock reconvergence pessimism 0.00 42.10
library setup time 0.00 42.10
data required time 42.10
---------------------------------------------------------------
data required time 42.10
data arrival time -3.10
---------------------------------------------------------------
slack (MET) 39.00

MUXs, Physical Exclusivity, and Crosstalk

The example shown above is correct for a non-SI analysis. However, some additional
considerations are needed to ensure correctness in a PrimeTime SI analysis.
Consider the last clock specifications above - we created two generated clocks at the divider
outputs, and then marked all three clocks as physically exclusive since only one clock at a time
could be present at the output of the MUX:

create_clock -period 10 CLK

create_generated_clock -name CLKdiv2 -divide_by 2 FFdiv2/Q -source FFdiv2/CK
create_generated_clock -name CLKdiv4 -divide_by 4 FFdiv4/Q -source FFdiv4/CK
set_clock_groups -physically_exclusive -group CLK -group CLKdiv2 -group
CLKdiv4

In an analysis where signal integrity (SI) effects are included, this is not necessarily true. What if
there was coupling between the outputs of the two dividers, as shown in Figure 2?

Figure 2: Coupling Between Divider Outputs

According to these constraints, CLKdiv2 and CLKdiv4 would never be simultaneously present
in the design, and PrimeTime SI should not compute any SI interactions (such as delta delays)
between these two clocks. While the two clocks cannot be simultaneously present downstream of
the MUX, they can interact with each other upstream of the MUX.

The correct way to specify the clocks in an SI analysis is to create generated clocks at:

 any point where the clock waveform is transformed (such as at the divider outputs),
PLUS
 any point where multiple clocks converge and become statically switched, such as at a
MUX output

First, we create the divided generated clocks:

create_clock -period 10 CLK

create_generated_clock -name CLKdiv2 -divide_by 2 FFdiv2/Q -source FFdiv2/CK
create_generated_clock -name CLKdiv4 -divide_by 4 FFdiv4/Q -source FFdiv4/CK

Next, we create the three MUXed versions of the clocks:

create_generated_clock -name CLK_mux -combinational UMUX/A -source UMUX/A

create_generated_clock -name CLKdiv2_mux -combinational UMUX/B -source UMUX/B
create_generated_clock -name CLKdiv4_mux -combinational UMUX/C -source UMUX/C

Note: We create the MUXed generated clocks at the MUX inputs to avoid the complexity of
creating multiple clocks on the same MUX output pin.
Finally, we apply the physically exclusive relationship to the three MUXed generated clocks
only:

set_clock_groups -physically_exclusive \
-group {CLK_mux} \
-group {CLKdiv2_mux} \
-group {CLKdiv4_mux}

Note that no clock group relationships exist between the clocks upstream of the MUX (CLK,
CLKdiv2, and CLKdiv4) because no timing paths exist between these clocks. If there were
additional flip-flops that were clocked off these pre-MUX clocks, then any cross-clock paths
would likely be valid. If they are not valid for functional reasons, an additional logically
exclusive relationship would be needed between these pre-MUX clocks.

Handling Cascaded Generated Clocks

Let's extend our example to consider the case where the MUX output feeds a final divide-by-3
flip-flop:

Figure 3: Clock Logic With Final Divide-By-3

In this case, the divide-by-3 flip-flop could potentially divide one of three different clocks. To
correctly handle this case, a unique divide-by-3 clock must be created for each potential clock
reaching the divider:

create_generated_clock \
-name CLK_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master CLK_mux
-add
create_generated_clock \
-name CLKdiv2_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master
CLKdiv2_mux -add
create_generated_clock \
-name CLKdiv4_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master
CLKdiv4_mux -add

As the clocks encounter subsequent transformations, we apply additional suffixes to the

generated clock names to track the transformation history of the clocks and avoid naming
conflicts. Once all clocks have been created, the clock group relationships are specified so that
the divide-by-3 clocks inherit the physical exclusivity property from their parents:
set_clock_groups -physically_exclusive \
-group {CLK_mux CLK_mux_div3} \
-group {CLKdiv2_mux CLKdiv2_mux_div3} \
-group {CLKdiv4_mux CLKdiv4_mux_div3}

The final set of commands for this example is:

# create parent clock

create_clock -period 10 CLK

# create divide-by-2, divide-by-4 generated clocks

create_generated_clock -name CLKdiv2 -divide_by 2 FFdiv2/Q -source FFdiv2/CK
create_generated_clock -name CLKdiv4 -divide_by 4 FFdiv4/Q -source FFdiv4/CK

# create "MUXed" versions of all clocks arriving at MUX

create_generated_clock -name CLK_mux -combinational UMUX/A -source UMUX/A
create_generated_clock -name CLKdiv2_mux -combinational UMUX/B -source UMUX/B
create_generated_clock -name CLKdiv4_mux -combinational UMUX/C -source UMUX/C

# create divide-by-3 versions of all clocks arriving at FFdiv3

create_generated_clock \
-name CLK_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master CLK_mux
-add
create_generated_clock \
-name CLKdiv2_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master
CLKdiv2_mux -add
create_generated_clock \
-name CLKdiv4_mux_div3 -divide_by 3 FFdiv3/Q -source FFdiv3/CK -master
CLKdiv4_mux -add

# apply physical exclusivity to all clock families (generated clocks included)

# which are exclusive due to statically switched MUX
set_clock_groups -physically_exclusive \
-group {CLK_mux CLK_mux_div3} \
-group {CLKdiv2_mux CLKdiv2_mux_div3} \
-group {CLKdiv4_mux CLKdiv4_mux_div3}