Asynchronous Clock Groups

Part II · Module 20 · Chapter 20.7 · Asynchronous Clock Groups

When two clocks have no fixed phase relationship, analysis still finds every path between their domains and checks it against some assumed relationship. Those checks are meaningless, and there are usually a great many of them.

A clock group declares the domains unrelated so the tool stops. It is the right instrument for the job, and it is also the one most often mistaken for a safety measure.

1. Related and unrelated clocks

=== three clocks, two domains ===
    core_clk   2.0
    ref_clk    10.0
    div2_clk   div2 of ref_clk

Three clocks, but two domains. div2_clk is generated from ref_clk (Chapter 20.2 §3), so the two are phase-locked — the tool knows exactly how their edges line up, and paths between them are perfectly analysable.

core_clk comes from somewhere else entirely. Nothing fixes its phase against the other two.

2. The declaration

set_clock_groups -asynchronous -group {core_clk} -group {ref_clk div2_clk}

=== declared asynchronous ===
    core_clk {ref_clk div2_clk}

Read it as: these groups are asynchronous to each other; clocks within a group are related.

So paths between the groups are no longer analysed, and paths within {ref_clk div2_clk} still are — which is correct, because those two have a real relationship.

3. Why this beats a pile of false paths

You could write a false path for each crossing. Three reasons not to:

• It states the real intent. "These two domains are unrelated" is one fact. Twenty false paths are twenty consequences of that fact, with the fact itself written down nowhere.
• It is symmetric automatically. Paths run both ways between two domains, and a false path covers one direction. Half of them get forgotten.
• It keeps working. Add a crossing next month and the clock group already covers it. The false-path list does not, and nobody will notice.

The general principle from Chapter 20.5 §7: prefer the exception that expresses the actual reason. A clock group says why; a false path says this one instance of why.

4. Where the grouping goes wrong

Two directions, both quiet.

Too coarse — putting related clocks in different groups. The tool stops analysing paths that genuinely needed checking. This is the dangerous one, and it looks exactly like success: fewer violations, a cleaner report.

Too fine — leaving genuinely unrelated clocks in the same group. The tool keeps reporting crossings nobody can meet, and the usual outcome is worse than the noise: somebody starts adding individual false paths to quieten it, which is how a constraint set becomes unreviewable.

The test for each pair of clocks: is there anything that fixes their phase relationship? A common source, a generated-clock declaration, a PLL that locks them. If yes, same group. If no, different groups.

5. It stops the check, not the hazard

This is the part to be unambiguous about.

It is worth noting that this is not something simulation rescues either: an RTL simulation cannot model metastability, so a crossing with no synchroniser can pass both timing analysis and simulation and still fail in silicon. The protection has to be structural.

So the order of work is: synchronise first, then declare the group. The declaration is bookkeeping about an intent the design has already implemented, not a decision in itself.

6. What to check

Three things, and the first two are scriptable:

Every clock is in exactly one group. A clock in no group is still being analysed against everything; a clock in two is a mistake.

Generated clocks are grouped with their sources. Derivable from the constraint set, since Chapter 20.2 recorded which clocks are generated and from what.

Every crossing between groups has a synchroniser. This one is not scriptable from the constraints — it is a design review, and it is the one that matters. Chapter 19.2's per-block clock listing is a useful starting point: a block with two arriving clocks from different groups is a crossing somebody should be able to point at the synchroniser for.

7. Exercises

Exercise 1. Three clocks, one generated from another. How many domains, and why?

Exercise 2. What does set_clock_groups -asynchronous stop, and what does it leave alone?

Exercise 3. Where does a generated clock belong, and what happens if you separate it from its source?

Exercise 4. Give three reasons a clock group beats a set of false paths.

Exercise 5. What is the test for whether two clocks belong in the same group?

Exercise 6. Does declaring clocks asynchronous make the crossing safe? What does?

Exercise 7. Why can simulation not be relied on to catch a missing synchroniser?