Dealing with asynchronous clock groups in

SDC
Learn about the Synopsys Design Constraints commands available for dealing with
timing challenges related to asynchronous clock domain crossings.
By Sanjay Churiwala
Director of Software Applications
Xilinx
and
Balachander Krishnamurthy
Senior Product Marketing Manager
Xilinx
Nowadays, most SoC designs use multiple clocks and commonly have many clock domains. As data crosses from one
clock domain to another within the design, the potential for metastability problems arises due to asynchronous
clock domain crossings (CDCs).

Figure 1: An asynchronous crossing with simple double flop synchronisation.

In figure 1, there is an asynchronous CDC for the data going from flop F1 (clocked by C1) into F2 (clocked by C2),
assuming that C1 and C2 are asynchronous with respect to each other.
Synchronisation
This asynchronous CDC at F2 can cause the F2 flip-flop's output to go metastable. Data from F2 can potentially be
read as different logic values if it feeds multiple logic paths if F2 enters the metastable state. The usual solution to
protect against such ambiguity is synchronisation. Figure 1 shows a simple synchronisation technique where the
data output of F2 feeds only one flip-flop (F3). In turn, F3 can feed into as many paths as desired -- subject to
meeting other electrical/design rules.
This additional flip-flop (F3) -- triggered by the same clock -- effectively gives the output from F2 one full clock cycle
to reach a stable logic value before being sampled by F3, which is then distributed to the rest of the design. (Many
more synchronisation techniques are used to combat metastability in addition to this simple double flip-flop
scheme, depending on the design needs.)
The timing challenge
Because clocks C1 and C2 are asynchronous with respect to each other, data originating from F1 can reach F2 at any
time with respect to F2's clock, C2. Data will sometimes arrive well before the active C2 clock edge, sometimes just
before the active edge (setup violation), sometimes just after the active edge (hold violation), etc. Timing analysis
tools consider the worst-case combination of all possible data and edge values, and these CDC paths result in setup
and hold violations being reported by the timing analysis tool because of the asynchronous timing between F1 and
F2.
The timing-analysis tools are not wrong in reporting violations. There will really be setup and hold violations at the
data input to F2. However, the design already has the mitigation plan for dealing with setup/hold violations through
EE Times-India | eetindia.com

Copyright 2013 eMedia Asia Ltd.

Page 1 of 3

the synchroniser (F3). Consequently, designers are not interested in seeing timing violations being reported at CDCs
where they have placed synchronisers. More importantly, the design tools may needlessly over-allocate resources
to those paths to meet timing, while starving other paths that could benefit from those extra resources.
Fixing this problem is therefore a real issue and not just a nuisance for the designer. An excellent way to tackle this
issue is through the use of appropriate constraints. The industry standard for constraint files is the Synopsys Design
Constraints (SDC) format, which specifies design intent, including timing, power, and area constraints. SDC has been
in use and evolving for more than 20 years, making it the most popular and proven format for describing design
constraints. For example, Xilinx incorporates the SDC format in its Xilinx Design Constraints (XDC) files used with
the Vivado Design Suite.
Conventional mitigation of the timing challenge
Before the set_clock_groups command became part of the SDC, designers would often use the set_false_path
command so that asynchronous CDC paths would not be timed and therefore no related errors would be reported.
However, using the set_false_path command for this purpose has several shortcomings as follows:
1. From the command itself, it appears that the path is not exercisable. In reality, it is exercisable. We just don't want
to time it, because there is an asynchronous CDC.
2. While we don't want to see any setup or hold violations reported on F2, this command allows this path as much
delay as it wants. In reality, we usually want to limit the path delay to some upper bound. The false-path relation
must be specified both ways -- for paths going from C1 to C2 and for paths going from C2 to C1 -- as follows:
set_false_path -from [get_clocks C1] -to[get_clocks C2] (covers the path shown in figure 1)
set_false_path -from [get_clocks C2] -to[get_clocks C1] (assuming another path exists where data crosses
from C2 to C1)
In reality, the synchronous versus asynchronous relationship between the C1 and C2 clocks does not depend on the
direction of data transmittal, so the need to specify it both ways with the set_false_path command is artificial.
3. If there are many interacting asynchronous clock domains, all of the asynchronous relationships must be
specified from each clock to each other clock:
set_false_path -from [get_clocks C1] -to [get_clocks {C2 C3 C4 . Cn}]
set_false_path -from [get_clocks C2] -to [get_clocks {C1 C3 C4 . Cn}]
An attempt to combine all these commands into a single command will be disastrous. The same clock name would
end up appearing in both from and to, causing the paths within the same clock to become false.
4. There is also the treatment of cross-talk analysis (which is beyond the scope of this article).
Consequently, many designers started replacing the set_false_path constraint with others, such as set_multicycle_path or set_max_delay, so that the constrained paths had some upper timing limit. This solution removed the
problem mentioned in point No. 2, but the other problems remained.
The set_clock_groups constraint command
1. The introduction of the set_clock_groups command to the SDC solved many of the above issues as follows:
2. The command itself acts as an explanation of the reasoning as to why the paths need not be timed.
3. The command has switches that distinguish among clocks that are asynchronous (-asynchronous), logically
exclusive (-logically_exclusive), or physically exclusive (-physically_exclusive). Thus, the command and its switches
act as second-level documentation.
4. The relationship is now specified with finer-grained resolution (asynchronous/logically exclusive/physically 5.
exclusive) so that the tools can perform cross-talk analysis.
The command specifies the relationship among the clocks. Once an asynchronous relationship is established, it
applies to paths in both the directions.
Irrespective of the number of asynchronous clocks, the asynchronous relationship can be specified in one single
command:
set_clock_groups -asynchronous -group [get_clocks C1] -group [get_clocks C2] -group [get_clocks C3] ...
However, in spite of being superior in all respects as compared to the previously used set_false_path command, the
set_clock_groups command still leaves one thing uncovered. From a timing-analysis perspective, the
set_clock_groups command (similar to the set_false_path command) prevents timing analysis of the paths between
asynchronous/logically exclusive/physically exclusive clock groups. While it is correct that paths between exclusive
clock groups need not be timed, designers might well want to specify an upper bound for the path delays between
asynchronous clocks for several reasons -- for example, to limit the skew on a FIFO-based synchronisation scheme
where read and write pointers are Grey-coded. Lack of timing for asynchronous paths is less of a limitation of the
the set_clock_groups command itself. The command contains enough information, but the tools' behaviour based on
the command prevents analysis of the asynchronous paths.
Current solutions
As a result, designers must once again resort to the set_max_delay or set_multi-cycle_path commands for paths
involving asynchronous clocks in order to set an upper-bound timing constraint.

EE Times-India | eetindia.com

Copyright 2013 eMedia Asia Ltd.

Page 2 of 3

If set_max_delay is specified between two clocks, the delay computation considers the delay differential on the clock
networks also. In such cases, the interest is primarily on the data-path delay. Thus, some tools extend the standard
SDC set_max_delay command to specify that only the data path delay has to be seen, while ignoring clock-path
delays. For example, the Xilinx Vivado Design Suite supports the switch -datapath_only.
Designers who do not have access to tools with these constraint extensions must use other, more complicated
methods. One such method is to define additional asynchronous clocks as ideal clocks to eliminate delays on the
clock networks. However, an ideal clock has an impact on paths within the same clock network, because skew
would no longer be considered.
For example, in figure 1, clocks C1 and C2 could be declared as ideal. However, these same clocks could be
triggering many other flip-flops, as well. These commonly clocked flip-flops interact amongst each other within the
same domain. Figure 2 represents another portion of the same figure 1 design, where clock C1 triggers flip-flops
F4, F5, and F6. These flip-flops have paths amongst themselves, and when clock C1 is declared as ideal, the timing
for paths amongst the flip-flops shown in figure 2 are also affected, which was not the designers' intent.

Figure 2: Using set_ideal_clock on C1 affects other paths, as well.

So, set_ideal_clock must be declared in such a way that only the circuits of interest are affected; other parts of the
design driven by the same clock should not be affected by this constraint. Paul Zimmer shows how convoluted the
situation can become in his paper "No Man's Land -- Constraining Asynchronous Clock Domain Crossings."
Conclusion
Timing-analysis tools should incorporate additional intelligence in treating set_clock_groups -asynchronous.
Paths spanning asynchronous clock groups should be timed to an upper limit (i.e. similar to set_max_delay,
but without clock network delays being considered) instead of not timing them at all. This upper limit could
(for example) be the lower of the two clock periods.
Another aspect that has been mostly ignored during all timing-analysis discussions relates to the path
between F2 and F3. An implementation tool would see this path as a path with one full cycle, with no
intervening logic, and with a single fanout. As a result, the tool may give lowest priority to this path, placing
these two flip-flops far apart or using worst-case routing for this path. However, this is a synchroniser, and
we want this path to be very fast, to give F2 the maximum possible time to settle and to minimise the
chance of a metastable condition.
ASIC methodologies minimise the delay on this path by creating the synchroniser as a cell macro that incorporates
both F2 and F3 with a pre-routed path between the two flip-flops so that implementation tools cannot place them
far apart.
For FPGA users, implementation tools like Xilinx's Vivado Design Suite provide user attributes (async_reg) so that
designers can specify close placement of F3 to F2, as well as using best possible (fastest) path routing.
Ideally, the tools should interpret the set_clock_groups -asynchronous constraint to also mean the synchronising
flip-flop must be placed as close as possible to the destination flip-flop.
Design tools supporting the above constraint behaviours will make life a bit easier for designers who will no longer
need to find convoluted ways to handle CDCs in their designs. This approach also averts the need to develop nonstandard constraint extensions to handle CDCs.

About the authors

Sanjay Churiwala is director of software applications for Xilinx and is based in Hyderabad, India.
Balachander Krishnamurthy is senior product marketing manager of static timing analysis for Xilinx and is based in
San Jose, Calif.

EE Times-India | eetindia.com

Copyright 2013 eMedia Asia Ltd.

Page 3 of 3