Clock Domain Crossing Demystified: The Second Generation...

Clock Domain Crossing Demystified: The Second Generation Solution

for CDC Verification Abstract: With the increasing trend towards SOCs, designs with multiple asynchronous clock domains are getting commonplace today. The design of asynchronous clock domain crossing (CDC) interfaces is required to follow strict design principles to ensure reliable operation in the presence of metastability. With the emergence of CDC verification tools, users have a way to verify their designs. However, first generation CDC tools provide inadequate support for a top-down, bottom-up CDC verification methodology. Also, extensive manual setup and signoff requirements create serious deployment limitations. This causes inconsistent usage of the tools and wasted engineering resources without covering the CDC failure risk. This paper describes an efficient, reliable and practical CDC verification methodology for effective timing closure verification (TCV).

1) Introduction: The increase in SOC designs is leading to extensive usage of asynchronous clock domains. The clock domain crossing (CDC) interfaces are required to follow strict design principles for reliable operation. Also, verification of proper CDC design is not possible using standard simulation and static timing analysis techniques. As a result, CDC verification tools have found increasing usage in the design flows. The first generation CDC tools allowed improved verification of CDC interfaces. However, these tools suffered from extensive manual and signoff requirements. As a result, the deployment of these tools posed challenges as the design size and complexity continued to increase. Hence, we are seeing ineffective usage of these tools, wasting engineering resources without covering the CDC failure risk. This paper makes a fundamental observation that the inability to accomplish timing closure across the CDC interface is the root cause of the CDC problem. This implies that effective data transfer across CDC interface requires design of a multi-cycle timing path. Also, the observation is made that traditional simulation and formal analysis techniques are incapable of analyzing transient design behavior, which is at the root of CDC failures. Hence, special formal analysis techniques are required for the CDC problem. Finally, the paper identifies practical considerations for effective CDC verification. It recommends a hierarchical top-down, bottom-up methodology, with result inheritance and effective use of formal analysis, to minimize the manual engineering effort in CDC verification. The paper is organized into eight sections, including this introduction. The second section introduces metastability and the CDC reliability problem. The third section introduces metastability fundamentals and principles for CDC interface design. The fourth section identifies the verification principles for CDC verification. The fifth section discusses practical usage of CDC tools and the engineering resource requirements. The sixth section outlines an efficient CDC verification methodology. Finally, the seventh section summarizes the metrics to evaluate the quality of CDC solutions. 2) Metastability and CDC fundamentals: A good understanding of the CDC problem requires an understanding of metastability and the associated design challenge. In this section we describe metastability and the CDC problem. 2.1) Understanding Metastability: When the latch input transitions within the setup and hold window around the latching clock transition, the latch output can become metastable at an intermediate voltage between logical zero and one. Figure 1 shows a simplified latch implementation. Metastable state is a very high-energy state as shown in Figure 2. Because of noise in the chip environment, this metastable voltage gets disturbed and eventually resolves to a logical value. The resolution time is dependent upon the load on the latch output

Real Intent Inc. & Sunburst Design, Inc.

and the gain through the feedback loop. However, it is impossible to predict this logical value. Also, there is an inherent delay in the resolution of the metastable output as shown in the timing diagram of Figure 3. This logical and timing uncertainty introduces unreliable behavior in the design and, without proper protection, can cause it to fail in unpredictable manners.

Figure 1: A Simplified Latch

Figure 2: The Metastability Energy Curve

Figure 3: Metastability Timing Diagram


For synchronous clock design, timing closure with static timing analysis ensures that all paths meet timing. Metastability is avoided and the design operates reliably. 2.2) Limitations of Functional Verification: Static Timing Analysis and Timing Closure Verification is needed: The prevalent functional verification methodology is based upon functional simulation. A simplified view of the simulation model is that the design behavior is evaluated using zero delay evaluation for logic, unit delay for flops and ideal clock behavior. Also, Formal Analysis makes use of the same evaluation assumptions. Hence, both of these techniques have an inherent limitation that they only analyze the steady state behavior of the design. Functional verification makes a fundamental assumption that Static Timing Analysis will account for clock behavior uncertainty caused by jitter and skews and ensure that all hazards in the design subside before the clock event (Timing Closure). This is the default timing rule. Functional verification will be invalidated if this assumption is violated. Static Timing Analysis allows users to specify exceptions to the default timing rules. These exceptions invalidate the functional verification and default timing assumptions. It is imperative that these exceptions be properly verified using Timing Closure Verification (TCV) for a robust design methodology. Since static timing of CDC interfaces is not possible and requires timing exceptions, CDC verification is a unique and essential component of TCV. 2.3) CDC terminology: A clock domain is defined as the set of all flops that are clocked by the associated clock. A clock domain crossing (CDC) is defined as a flop-to-flop path where the transmitting flop is triggered by a clock that is asynchronous to the receiving flop clock. These two clock domains are considered to be relatively asynchronous. Figure 4 describes the CDC terminology used in this paper. The receiving flops are referred to as CDC flops. The signals feeding the CDC flops are referred to as CDC signals.

Figure 4: Defining CDC Terminology


2.4) Unavoidable Metastability and the CDC problem: Asynchronous clocks operate without any mutual frequency and phase relationships. As a result, it is impossible to guarantee timing on CDC paths because the launch and capture clock edges can be arbitrarily close. Hence, metastability is unavoidable for CDC designs. This invalidates both functional simulation and formal verification assumptions and robust design behavior can’t be assured using simulation and Static Timing Analysis. Without proper design, CDC errors can cause random and unpredictable failures in the chip that are impossible to debug. 2.5) CDC Errors: Metastability introduces the following failure modes in the design: E1) Loss of correlation. This happens when two or more correlated CDC flops become metastable as shown in Figure 5. Figure 6 shows the timing diagram where these flops resolve to arbitrary logical values and hence, lose correlation leading to a bad design state. E2) Hazard capture. A hazard on a CDC path can get captured in the CDC flop leading to bad design state as shown in Figure 7. E3) Loss of signal. CDC signals that are stable for less than one clock cycle of the receiving clock may not get captured in the receiving domain because of clock network uncertainties, clock alignment and metastability. Figure 8 shows the situation where functional verification view concludes signal transmission. However, the signal transmission can actually fail leading to a bad state in the design. E4) Metastability propagation. Metastability may propagate to the next level of flops in the design if it is not resolved in a timely manner. The resolution time is dependent upon the load on the flop. Propagation of metastability may lead to cascading of errors E1-E3.

Figure 5: Loss of Correlation


Figure 6: Loss of Correlation Timing Diagram

Figure 7: Glitch Capture


Figure 8: Loss of Signal

3) CDC Design Principles: Metastability is unavoidable in CDC designs. As a result, robust design of CDC interfaces is required to follow some strict design principles as covered in this section. 3.1) Containing Metastability with Synchronizers: A synchronizer is a device to contain the metastability effects from propagating into the design. Figure 9 shows a double flop synchronizer. This configuration minimizes the load on the metastable flop. The single fanout protects against loss of correlation since the metastable signal does not fan out to multiple flops. The probability that metastability will last longer than time t is governed by the following equation:

where τ is the resolution time constant dependent upon the latch characteristics and ambient noise. This configuration resolves metastability with a very high probability leading to a very large mean time between failures as governed by the equation:


where P is the probability that metastability is not resolved within one clock cycle. Triple or higher flop configurations may be used for very fast designs.

Figure 9: Double Flop Synchronizer Contains Metastability 3.2) Designing CDC Interfaces: A CDC interface is designed for reliable transfer of correlated data across the data bus. Reliable design of a CDC interface must follow a simple set of rules:

1) The CDC data bus must be designed for 2-cycle multi-cycle-path operation (MCP). This means that data is captured in the CDC flops on the second clock edge or later, following the launch of data. This also gives one clock cycle of the receiving clock as the timing constraint on the path. Static timing analysis should ensure that the timing constraints are met on these paths. This rule eliminates metastability for these paths. As data bus signals are correlated, their CDC flops can not be allowed to become metastable.

2) The control signals implementing the MCP protocol can become metastable and hence must follow the following rules:

a. The controls must be properly synchronized to prevent propagation of metastability in the design.

b. The MCP is enabled by one and only one control signal transition to eliminate loss of correlation errors (Gray Coding).

c. The control signals should be free of hazards/glitches. d. The control signals must be stable for more than one clock cycle of

the receiving clock.

These principles can be implemented using handshake protocols or FIFO based protocols. Figure 10 shows a simple handshake CDC protocol. This interface is transmitting data from CLK1 domain to CLK2 domain. While Data Ready is asserted, the data on the bus Data In is transmitted across the clock domain. The data availability is signaled by a transition on Control Signal. Transmit Data is launched on the same clock edge. Control Signal is synchronized in the CLK2 domain and the transition is detected to signal Load Data. Since, synchronization requires at-least one cycle of CLK2, Transmit Data is received at the second edge of CLK2 or later. This creates a multi-cycle path for Transmit


Data across the interface. Feedback Signal completes the handshake. Transition on Feedback Signal is detected to drive Next Data to the interface. Figure 11 shows the timing diagram for the protocol. It should be noted that this is a simplified concept of the interface. We have not incorporated the logic initializing the interface, detecting transition in Data Ready and dealing with stalling conditions. All these considerations, combined with latency minimization add complexity to the design of the interface. A good treatise on FIFO based protocol can be found in (Cummings, 2001)

Figure 10: Simple Handshake CDC Protocol


Figure 11: CDC Protocol Timing Diagram 4) Verifying CDC Interfaces: A typical SOC is made up of a large number of CDC interfaces. From the discussion above, CDC verification can be accomplished by executing the following steps in order:

1) Identification of CDC signals 2) Classification of CDC signals as control and data 3) Hazard/Glitch robustness of control signals 4) Verification of single signal transition (Gray Coding) of control signals 5) Verification of control stability (Pulse Width requirement) 6) Verification of MCP operation (stability) of data signals

All verification processes are iterative and achieves design quality by iteratively identifying design errors, debugging and fixing errors and re-running verification until no more errors are detected 5) Practical considerations for CDC Verification: Effective deployment of CDC tools in the design flow requires due consideration of multiple factors. We have discovered that the first generation CDC tools were not being used effectively in design flows. Based upon feedback from users, we have identified the following factors as most important considerations for CDC deployment:

1) Coverage of error sources 2) Design setup cost 3) Debugging and sign-off cost


4) Verification run-time cost 5) Template recognition vs. Report quality tradeoff 6) Top level vs. Block Level verification tradeoff 7) RTL vs. Netlist verification tradeoff

There is consistent feedback from the users that the minimization of engineering cost for high quality verification is critical for effective deployment of the CDC tools. 5.1) Coverage of error sources: CDC errors can creep into a design from multiple sources. The first is inadvertent clock domain crossing where there is an assumption mismatch or oversight at block interfaces. The second is faulty block level design. The designers, because of oversight or because of the pressure to design correct and high performing interface, can make a design error. As an example, consider the protocol in Figure 12. Here, tapping Feedback Signal from an earlier flop stage can reduce the latency across the interface. However, correct operation of this interface requires that the transmitting clock frequency be slower than the receiving clock frequency. Otherwise, it is possible to signal New Data before Load Data is completed.

Figure 12: Reduced Latency Protocol These two error sources are properly covered by RTL analysis. They can also be covered by Netlist analysis. However, not all CDC error sources are covered by RTL analysis. That is because CDC errors are dependent upon glitches and hazards. It is a well-known phenomenon that synthesis transformations can introduce hazards in the design. Hazards in CDC logic lead to CDC failures. Figure 13 shows an example of a design failure caused by synthesis. Here the multiplexor implementation created a logic hazard that violated the multi-cycle path requirement on the data bus. We are aware of multiple design failures because of this phenomenon.


Figure 13: Logic Hazard Caused CDC Failure With the increasing complexity of SOCs and increasing number of CDC interfaces on the chip, the contribution of this risk factor is increasing. As a result, CDC verification must be run on both RTL and Netlist views of the design. 5.2) Design setup cost: Design setup starts with importing the design. With the increasing complexity of SOCs, designs include RTL and netlist blocks in a Verilog and VHDL mixed language environment. In addition functional setup is required for good quality of verification. A typical SOC has multiple modes of operation characterized by clocking schemes, reset sequences and mode controls. Functional setup requires the design to be set up in functionally valid modes for verification, by proper identification of clocks, resets and mode select pins. Bad setup can lead to poor quality of verification results. Given the design management complexity for the multitude of design tasks, it is highly desirable that there be a large overlap between setup requirements for different flows. For example, design compilation can be accomplished by processing the existing simulation scripts. Also, there is a large overlap between the functional setup requirements for CDC and that for static timing analysis. Hence, STA setup, based upon SDC, can be leveraged for cost effective functional setup. Correct functional setup of large designs may require setup of a very large number of signals. This cumbersome and time-consuming drudgery can be avoided with automatic setup generation. Also, setup has the first order effect on


the quality of verification. Hence, early feedback on setup quality can lead to easy and effective setup refinement for high quality of verification.

Figure 14: Design Setup Flow 5.3) Debugging and sign-off cost: The debugging cost is dependent upon the number of errors flagged by the CDC tool. Assuming good setup, this in turn depends upon the size and CDC complexity of the design and the maturity of the design. Typically, debugging cost for top-level runs on immature designs will be high. This is because the design may contain a large number of immature CDC interfaces. This can generate a large number of failures requiring significant debugging effort. Also, the ownership of these CDC interfaces may be distributed between multiple designers. Debugging cost is heavily dependent upon the reporting style of the tools. The source code oriented reporting relates the errors to the real source: HDL


functionality. Also, it produces much more compact reports. CDC verification employs multiple technologies of increasing sophistication, like structural analysis and formal analysis. Hence, a composite report is essential to determine the overall quality of CDC verification. Good clock domain, functional, structural and VCD visualization is essential for effective debugging. Automated and advanced preprocessing of these views, to isolate the error context, further reduces the debugging cost. Finally, debugging support requires advanced sign-off capabilities so that the same issues are not analyzed multiple times in the iterative verification flow. 5.4) Verification run-time cost: CDC checking is based upon multiple technologies with varying degree of precision. In the first step structural techniques are used to identify clock domain crossings and to identify possible error sources in the design. Structural analysis tends to be relatively fast and is very useful at detecting gross errors in the design. However, in order to guarantee design correctness, structural analysis identifies all potential errors in the design. This set can be very large. As an example, consider the design in Figure 12. This reduced latency design can operate correctly or can be erroneous depending upon the relative frequency of the clock domains. Also, this structure can be included in a more complex interface that handles stall and other issues making precise structural identification difficult. If a structural technique does not compromise the quality of checking, it has to flag this interface for manual review and signoff. Formal analysis is an excellent technology to filter out false failures from structural analysis and to precisely identify failures in the design. As mentioned before, traditional formal analysis is built to analyze steady state design behavior. Hence, these formal techniques are incapable of formally analyzing uncertain behavior because of metastability and glitches. As a result, special formal analysis techniques, that are capable of handling behavioral uncertainty, are needed for CDC applications. For example, consider the failure shown in Figure 13. Here the MCP on data path is violated because of a hazard. Vanilla formal analysis will pass the data stability check (MCP) for this structure. Data stability for CDC interfaces can only be proven with glitch sensitive formal analysis techniques. Formal application needs to be seamlessly integrated into the application all the way from invocation to reporting and debugging. This eliminates a huge overhead of integrating external formal analysis tools into the flow and to correlate the results from these different tools to arrive at an integrated view of verification status.


As the computational complexity of formal analysis is very high, this can require a large amount of computation time. However, this cost is well worth as it provides significant savings in debugging and sign-off cost.

Figure 15: Verification and Debug Flow 5.5) Template recognition vs. Report quality tradeoff: The first generation CDC tools employed structural analysis as the primary verification technology. Given the lack of precision of this technology, users are often required to specify structural templates for verification. Given the size and complexity to today’s SOCs, this template specification becomes a cumbersome process where debugging cost is traded off for setup cost. Also, the checking limitations imposed by templates may reduce the report volume but they also increase the risk of missing errors. In general, template based checking requires large manual effort for effective utilization. 5.6) Top-level vs. Block Level verification tradeoff: The top-level verification reduces the setup requirements for CDC verification but can result in higher


debugging cost as the design maturity improves iteratively. On the other hand, block-level verification identifies errors earlier and at smaller complexity levels there by creating a cleaner top-level verification. Hence, top-level debugging cost reduces but the overall setup and run-time cost increases. 5.7) RTL vs. Netlist verification tradeoff: As mentioned before, Netlist analysis can cover all the CDC error sources. The debugging cost is very high for application at the Netlist level. Also, the delay in detecting errors until much later in the design cycle can have a serious schedule impact. However, RTL analysis does not cover all CDC error sources. This requires that CDC verification must also be run on Netlists. 6) A practical and efficient CDC verification methodology: After evaluating the various considerations as mentioned above, we recommend the following CDC verification methodology to accomplish high quality verification with minimal engineering cost:

1) Automatically create the functional setup the top-level design leveraging SDC.

2) Automatically complete the functional setup. 3) Use setup verification techniques to refine top-level functional setup. 4) Identify the sub-blocks for initial CDC verification. 5) Automatically generate block level functional setup from the top-level. 6) Run thorough block level CDC verification.

a. Examine the generated functional setup for correctness. b. Run structural analysis. c. Identify and fix gross design errors or refine functional setup. d. Run formal analysis for precise error identification. e. Debug and fix design or refine functional setup. f. Iterate verification steps until clean.

7) Run thorough top-level CDC verification with block level result inheritance. 8) Run thorough Netlist CDC verification.


Figure 16: Top Down-Bottom Up Verification Flow


7) A framework for evaluating CDC solutions: Based upon the above presentation, we have formulated the metrics for evaluating the quality of CDC solutions. Our attempt is to summarize the relationship between various attributes. We use a generic symbol f(attribute) to represent the quantification associated with the attribute. For example, f(types_of_err) is the factor contributed the extensiveness of error checking conducted by the tools and f(templ_req) is the factor measuring the complexity of setting up the checking tem a e dpl tes. These metrics ar efined below.

1 _ – _

_ – 2 _

2 _ _ _

3 .

4

_ _ _ _

5 # _

# _

6 ,# _ _

7 _ , _ _ _

The diagram below shows graphically the results of these equations.

Figure 17: Spiderchart for 1st and 2nd Generation CDC Tools


About the Authors: Prakash Narain, PhD


Real Intent, Inc. Dr. Prakash Narain is the President and CEO of Real Intent, Inc. Prior to founding Real Intent, his career spanned IBM, AMD and Sun where he got hands on experience with all aspects of IC design, CAD tools design and methodology. He was the project leader for test and verification for UltraSPARC IIi at Sun Microsystems. He was an architect of the Mercury Design System at AMD He has architected and developed CAD tools for test and verification for IBM EDA. Dr. Narain has a Ph.D. from the University of Illinois at Champaign-Urbana where his thesis focus was on algorithms for high level testing and verification.

Clifford E. Cummings Sunburst Design, Inc. Cliff Cummings is President of Sunburst Design, Inc., a company that specializes in world-class Verilog, SystemVerilog and synthesis training. Cliff has presented more than 90 SystemVerilog seminars and training classes over the past five years and was the featured speaker at the worldwide SystemVerilog NOW! seminars in 2003. Cliff has participated on every IEEE & Accellera Verilog, Verilog Synthesis, and SystemVerilog committee, and has presented some 40 papers on Verilog & SystemVerilog related design, synthesis and verification techniques.

Cliff holds a BSEE from Brigham Young University and an MSEE from Oregon State University.

Bibliography Cummings, C. (2001, 3 31). Synthesis and Scripting Techniques for Designing Multi-Asynchronous Clock Designs. Retrieved 2 1, 2008, from Sunburst Design, Inc.: http://www.sunburst-design.com/papers/CummingsSNUG2001SJ_AsyncClk.pdf

Clock Domain Crossing Demystified: The Second Generation...

Documents

Transcript of Clock Domain Crossing Demystified: The Second Generation...