Seemingly Simple Clock Relations Quiz

Feb 6th, 2020   |   Hollis , Robertson

Getting clock relationships correct is very important.  In order to get the “set_clock_groups” constraints correct the designer must specify the correct clock pair relationship.  If the relationship is incorrect it could lead to over pessimism in Crosstalk/SI analysis, or worse, false path between synchronous clocks. For example, it would be incorrect to specify a clock pair as asynchronous when it is in fact physically exclusive or logically exclusive.

Below are the user clock constraints and four “set_clock_groups”:

create_clock -name CLKA -period 1.00 [get_ports CLKAB]

create_clock -name CLKB -period 1.50 [get_ports CLKAB] –add

create_clock -name CLKC -period 2.30 [get_ports CLKC]

create_generated_clock -name CLKA_DIV2 -divide_by 2 \

-master [get_clocks CLKA] -source [get_ports CLKAB] \

[get_pins div2/Q] -add

create_generated_clock -name CLKB_DIV2 -divide_by 2 \

-master [get_clocks CLKB] -source [get_ports CLKAB] \

[get_pins div2/Q] –add

set_clock_groups -asynchronous -group {CLKA} -group {CLKB}

set_clock_groups -logically_exclusive -group {CLKB} \

                                      -group {CLKB_DIV2}

set_clock_groups -asynchronous -group {CLKB} -group {CLKC}

set_clock_groups -asynchronous -group {CLKC} -group {CLKA}

Take a look at the schematic and the clock constraints to see if you can make a table of every clock pair and its relationship. Also, try to figure out the incorrect and missing “set_clock_groups”.  Be honest, don’t look at the Timevision generated table for help.

How did you do?  Not as simple as it seemed, was it?  Imagine trying to figure out the clock pair relationships of a 100M instance SoC with 1000 clocks!  How is this done in your current work flow?

Ausdia’s Timevision has patented technology to dramatically simplify this task.  This patented technology coupled with Timevision “Check SDC Module” can verify that all your “set_clock_groups” constraints exist and are correct, to ensure your Crosstalk/SI analyses are not pessimistic, and there are no false path between synchronous clocks.  If you prefer not try to figure out the clock relationship of 1000 clocks, Timevision can generate all your “set_clock_groups” constraints.

Below is a list from Timevision of every clock pair relationship from the user SDC and Timevision inferred relationships.  Note the “WRONG” “set_clock_groups”. Also, “null” in the user SDC column means there is no user specified relationship between the clock pair in the SDC.  In the case of synchronous clocks that is a good thing.

Table 1

A “set_clock_group -asynchronous” between clocks CLKA and CLKB causes Crosstalk/SI pessimism because they are in fact physically_exclusive and therefore no STA should be performed between CLKA and CLKB at all.

Also, “set_clock_group –logically_exclusive” between clocks CLKB and CLKB_DIV2 masks true timing paths in unique-to-unique domain in STA, resulting in un-optimized setup/hold timing paths.

Below are Timevision generated “set_clock_groups” for every clock pair that should have a “set_clock_group”, and they are “type” correct. 

Timevision Generated “set_clock_groups”

set_clock_groups -physically_exclusive -group {CLKB_DIV2}\

                                       -group {CLKA_DIV2}

set_clock_groups -physically_exclusive -group {CLKB} -group {CLKA}

set_clock_groups -physically_exclusive -group {CLKB_DIV2}\

                                       -group {CLKA}

set_clock_groups -physically_exclusive -group {CLKB}\

                                       -group {CLKA_DIV2}

set_clock_groups -logically_exclusive -group {CLKB_DIV2} -group {CLKC}

set_clock_groups -logically_exclusive -group {CLKC} -group {CLKA_DIV2}

set_clock_groups -asynchronous -group {CLKB} -group {CLKC}

set_clock_groups -asynchronous -group {CLKC} -group {CLKA}

Remember that 1000 clocks SoC?

That’s 1000 X 1000 clocks, ONE MILLION clock pairs!

How would you figure out and verify 1,000,000 clock pair relationships?  

Until next time, Happy Clock Grouping!!!!