Synchronous vs Asynchronous clocks:

2 clocks are synchronous w.r.t. each other if they share
i) common source
ii) fixed phase relationship

Unless we specify otherwise, PT assumes that 2 clocks are synchronous if there is any path with data
launched by one clock and captured by the other clock.

The clock waveforms are synchronized at time zero, as defined by the create_clock command. For example, consider below 3 commnads.

pt_shell > create_clock -period 4 -name CK1 -waveform {0 2}
pt_shell > create_clock -period 4 -name CK1 -waveform {1 3}
pt_shell > create_clock -period 6 -name CK1 -waveform {2 3}

PT creates the clocks as specified in the commands, with the waveforms synchronized. PT adjusts timing relationship further for any specified or calculated latency or uncertainity.

1. In a design that uses these 3 clocks, there might be paths launched by one clock and captured by         another clock.
2. When such paths exist, to test all possible timing relationships b/w different clock edges, PT internally expands the clocks to the LCM of all synchronous clock periods, thus creating longer period clocks with multiple rising and falling edges.

3. The  LCM of these periods called base period is 12.

4. To analyze the paths that cross the clock domains, PT internally expands the clocks by repeating them over the base period.

For multi-freq clocks:
Which edges need to be considered for Setup and Hold times calculation:
1. Evaluate waveforms over smallest common base period.
2. For each capture edge, find the closest setup launch edge. Call these the primary pairs.

For Setup:
3. Out of the primary pairs, pick the most restrictive setup launch and capture edges.

For Hold:
4. For each primary pair, draw 2 hold relationships: Launch to (Capture-1); (L+1) to Capture. Form all of these hold relationships, pick the most restrictive.

Asynchronous clocks:
Two clocks are asynchronous if they don't communicate with each other in the design.

When 2 clocks are defined as asynchronous, PT doesn't check the timing paths launched by one clock and captured by the other clock, which is like declaring a false path b/w the 2 clocks.

In addition, if you are doing xtalk analysis, PT-SI assigns infinite arrival windows to the nets in aggressor-victim relationships b/w the 2 clocks domains.


###############
To specify in PrimeTime:

#clk1 and clk2 are asynchronous:
set_false_path -from [get_clocks clk1] -to [get_clocks clk2]
set_false_path -from [get_clocks clk2] -to [get_clocks clk1]

# A preferable method, which is portable to PTSI
set_clock_groups -asynchronous -group clk1 -group clk2

##Single Analysis with multiple clocks:
#  Specify exclusive clock groups:
set_clock_groups -logically_exclusive -group clk1 -group clk2
set_clock_groups -logically_exclusive -group clk3 -group clk4

# selecting clk groups with SEL signal and specifying logically exclusive clock groups
set_clock_groups -name SEL -logically_exclusive \
          -group "clk1 clk3" \
          -group "clk2 clk4"

# Defining CLK1 has a range of possible duty cycles -> 40/60 to 60/40
create_clock -name CLK1a -period 10 -w {0 4} [get_ports CLK1]
create_clock -name CLK1b -period 10 -w {0 6} [get_ports CLK1] -add

set_clock_groups -exclusive -group CLK1a -group  CLK1b
set_clock_groups -exclusive -group "CLK1a CLK1b CLK3" -group "clk2 clk4"