Understanding clock domain crossing issues

Verification Methodology

This section describes a methodology which will ensure that the circuit has been designed properly to handle the clock domain crossing issues described in Sections 2 and 3.

The validation activity can be divided into two categories, namely structural and functional. Structural validation ensures that appropriate synchronization logic has been added wherever it is required and functional validation ensures that the logic which has been added is actually performing the intended function.

A number of CDC problems can be detected just by performing structural validation. These checks are simpler and much faster than the functional validation. Moreover, if there are structural issues, most of the functional validation would have no relevance anyway. Hence, verification should begin with the structural checks and the problems detected there should be corrected before moving on to functional validation.

Rule-based checking is a very efficient way to perform structural validation.

Assertion-based verification techniques can be used to perform functional validation. Assertions can be inferred automatically in the design using some EDA tools, or they can be inserted in the RTL using any of the standard assertion languages like OVL, PSL and SVA. These languages are supported by many EDA vendors.

These assertions can either be simulated in the functional simulation environment or can be verified using formal verification techniques. Both these techniques have their own advantages and disadvantages.

The simulation results are dependent on the quality of test vectors used. A problem may go undetected if the vectors applied cannot stimulate it, and it is very difficult to determine the right set of test vectors which will give good coverage.

As compared to simulation, formal techniques give a much better coverage and there is no need to provide any test vectors. However, formal techniques have some performance issues because of state space explosion which is a well known problem in formal analysis [4]. So, these checks are not suitable for full chip analysis but they work reasonably well at the block level.

A step-by-step approach for verifying clock domain crossings is described here.

Step 1

Check for the presence of valid synchronizers in:

1. All asynchronous clock domain crossings, and,
2. Those cases of synchronous clock domain crossings where there can be metastability as described in the section on rational multiple clocks.

A multi-flop synchronizer is sufficient to ensure that there will be no metastability. However, there can still be a problem of data incoherency. So, it is advisable to check at this stage only, that multi-flop synchronizers are used only for scalar signals. They can also be used for control busses. They should not be used for data busses however.

A rule-based checker can be used to automatically detect all clock domain crossings and to check for the presence of valid synchronizers at all places where they are required.

If there are missing synchronizers, the designer should modify the design to add appropriate synchronization logic.

Step 2

Check for the presence of separately synchronized signals which are converging. These are probable candidates for data incoherency. These candidates can be identified by doing structural analysis of the design.

The candidate signals for data incoherency should be verified to be Gray-encoded. This validation can be done through assertions. The assertion itself could even be generated by a structural checking tool – whenever it sees signals which are candidates for data incoherency.

Figure 15, shows a control bus clock domain crossing, which is synchronized using a multi-flop synchronizer but is not Gray-encoded. A waveform trace is generated for the assertion failure.

Figure 15.        Gray-encoding failure using formal verification

In case the converging signals cannot be Gray-encoded, change the synchronization scheme to one which uses a common control signal, for example, MUX recirculation, FIFO or handshake. These schemes still need to be validated for proper functionality as described in Step 4.

Step 3

Once the proper synchronization logic is in place and the Gray-encoding checks have been done, the next step is to verify that there is no data loss while transferring data from one clock domain to the other. This needs to be checked for the following two cases:

• Synchronous clock domain crossings
  • All fast to slow crossings
  • Slow to fast crossings where the clock edges can be close together for continuous cycles
  • All asynchronous clock domain crossings

These can be validated by asserting that each source data launch is always captured in the destination domain.

In the case of fast to slow synchronous clock domain crossings, where a synchronizer is not required and for the simple cases of multi-flop synchronization, check that after every transition on the source data an active edge of the destination clock arrives where there is no setup or hold violation.

For other synchronization schemes, some standard functional checks can be done to ensure that there is no data loss, which are described in Step 4.

Step 4

In all cases, where some special synchronization schemes are used, it is necessary to verify that they are performing the intended function correctly. This is important to ensure that there will be no metastability, data incoherency or data loss problem.

The required checks are given here for three commonly used schemes:

• Handshake synchronization: Check that the request-data and request-acknowledge protocols are working as per the specifications.
• FIFO synchronization: Check that there is no FIFO overflow or underflow.
• Mux recirculation: With reference to Figure 8, check that while the synchronized control signal EN_Sync is active, the following two conditions hold:
  • Source data A[0:1] is stable, and,
  • at least one active edge of destination clock arrives

The methodology described in the above four steps is also depicted in Figure 16.

Figure 16.        Verification methodology

Summary

Traditional verification methods like simulation and static timing analysis are not sufficient to detect all types of problems which can occur in clock domain crossings. The problems which can occur depend on the types of clock domain crossings. Similarly, the solutions to those problems are also different and hence the verification techniques required are different as well. Some of the basic problems of clock domain crossings have been discussed here. The solutions to those issues are also discussed and a verification methodology is proposed which will ensure that data is correctly transferred across clock domains.

References

[1]        Sanjay Churiwala, “Tackling multiple clocks in SoCs”, EE Times March 15, 2004.

[2]        Shaker Sarwary, “Solving the toughest problems in CDC analysis”, EE Times August 28, 2006.

[3]        http://www.asic-world.com/tidbits/metastablity.html

[4]        K. McMillan, Symbolic Model Checking, Kluwer Academic Publishers, Boston, 1993.

About the Authors

Saurabh Verma Is an engineering manager at Atrenta. He has a bachelor degree from Indian Institute of Technology, Kanpur.