EE Times-India | eetindia.com Copyright 2013 eMedia Asia Ltd. Page 1 of 3

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 2 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_multi-

cycle_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 3 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 non-

standard 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.