Atrenta, Inc.

SpyGlass-CDC: Combining Structural and Functional Verification Techniques to Improve Effective Clock Domain Crossing Verification

White paper

Atrenta, Inc.

Introduction
Multiple, independent clocks are quintessential in SoCs and other complex ASICs today. In extreme cases, such as in large communications processors, clock domains may number in the thousands. Clock domain crossings pose a growing challenge to chip designers, and constitute a major source of design errors--errors that can easily slip past conventional verification tools and make their way into silicon. When these errors make it into silicon, the costs are high. A single silicon re-spin may cost $10 million and extend time-tomarket by months, greatly reducing the chips market share and profit potential. Even if caught prior to silicon in the late stages of design, a bug may still run up $100,000 or more in redesign costs. Therefore, there is a substantial benefit to identifying and correcting CDC problems in the early stages of the design, at the RTL level, when corrections may be made quickly and at minimal cost (a few hundreds or thousands of dollars). Unfortunately, cycle-based simulation, the mainstay of RTL-stage verification, is not well suited to finding and tracing timing-related errors resulting from CDC problems. Traditional structural analysis tools can help identify potential problem areas, but none offers the kind of comprehensiveness or precision users require. Such tools tend to simultaneously overlook a number of real design errors and over-report a large numbers of false violations. The CDC problem therefore calls for next-generation tools that provide more advanced CDC verification. As this paper describes, these tools must combine a number of techniques-including both structural analysis and functional, assertion-based checks. Only in this way can new tools provide the completeness and accuracy that CDC verification demands.

CDC Definition and Problem Description

A clock domain is any area governed by a single clock, or by multiple clocks with fixed phase and frequency relationships. Areas whose clocks lack a constant phase and time relationship are defined as separate clock domains. When signals cross between such asynchronous domains, several problems can result: Metastability: Due to out-of-phase clocks, a signal passing from one domain to another may be changing when it is sampled by the receiving domain. That is, the incoming signal may transition within the setup or hold time of the receiving domains clock. As a result, the signal may be captured at some intermediate voltage level between valid logic levels. This may cause the receiving flip-flop to become metastable: settling temporarily at an intermediate, non-logic level and taking some time to return to a stable state. If the output of this flip-flop is in turn sampled while at an intermediate level, the metastability may be propagated to downstream logic, causing unpredictable logic transitions. A common synchronization solution is to capture the signal through two cascaded flip-flops. The first may be metastable as described, but the probability of the second also settling at a metastable state is very low. The two-flop solution extends the mean time between failures (MTBF) from hours in the case of one flop to something on the order of 100,000 years. The two sequential flops thus eliminate metastability problems for all practical purposes, and to ensure that the output is synchronized with the receiving clock domain.

Figure 1: Basic synchronizers

Atrenta, Inc.
Mux re-circulation scheme

Mux lock scheme

Figure 2: More complex synchronization schemes

Data loss or corruption: Two-flop synchronizers address the metastability problem, making sure that the values coming out of the synchronizer are in fact stable, but such sync schemes dont by themselves guarantee that the values are correct. For example, when a signal crosses from a domain with a faster clock to a domain with a slower one, the receiving domain may simply miss one or more incoming bits (if the bits fall between sampling intervals on the destination domain). In other circumstances, the correlation between incoming signals may be lost. For example, two signals may be subject to different delays when crossing domains, and even slight differences in latency might cause the signals to fall out of correlation. Additional logic--over and above a basic synchronizer--may therefore be necessary in some situations to maintain data integrity. Techniques include the use of gray coding on buses and data-stretching or handshake methods in fast-to-slow crossings (see below for more explanation).

Simulation is Inadequate
Traditional verification tools such as cycle-based simulators are not intrinsically capable of detecting timing-dependent effects such as metastability and other timing-related CDC errors. And even when simulation does detect a bug stemming from a CDC error, it provides no means of tracing the problem to its source in the RTL.

Solution Requirements
Any comprehensive solution to the CDC problem requires a number of key capabilities:

Identifying Clock Domains

Atrenta, Inc.

The first task of any CDC verification tool is to identify all of the clock domains on the chip. This requires structural analysis thorough enough to detect derived clocks (clocks derived from other clocks) and muxed clocks (i.e., multiple clock signals muxed together on same path, where the select value determines which clock is actually used). After finding all the domains, the tool should display them in the RTL for the designer to view.

Figure 3: Analysis of clock domains

An important related capability is case analysis to detect mode-dependent crossings--i.e., crossings that exist only between exclusive operational modes, such as functional and test modes (more on this below). The tool should also display all clock trees, indicating the logic in each tree. This allows designers to see all clocks and their relationships, and to understand logic function in the clock trees. Identifying unsynchronized crossings: After domains and crossings are identified, the tool must then pinpoint potential CDC problems. The largest and most obvious group of potential trouble spots is domain crossings that lack any apparent synchronization. Unsynchronized crossings are detected using structural analysis and are reported in abundance by traditional CDC tools. Such tools typically find hundreds of such violations per chip. And, unfortunately, are far too indiscriminate in their approach, and most such violations--roughly 90 percent on average--turn out to be red herrings. The large number of false violations is, in fact, the single biggest shortcoming of conventional CDC tools. Users are left with the time-consuming work of sifting through violation reports to find the real problems, greatly limiting the usefulness of the tool. It is therefore imperative that new-generation tools take steps to minimize these false alarms.

Atrenta, Inc.

Figure 4: The approach to reducing false violations in CDC verification

Weeding Out False Violations

There are several major classes of false violation, and a variety of approaches are needed to exclude them from the final violation report: Mode dependent clock domain crossings: Many conventional tools lack the ability to analyze operational modes such as test mode and other functional modes that enables identification of relevant clock domains. As a result, conventional tools often mistakenly identify crossings between clock domains that are not true crossings, thus adding numerous false violations into the reports. To address this problem, tools should provide methods such as case-analysis to automatically find and exclude such false crossings from violation reports.

Figure 5: Case analysis is a requirement for CDC verification

Atrenta, Inc.
Quasi-static signals: Certain signals--such as reset and other configuration signals--are quasi-static. That is, they are effectively stable for long periods of time. Such crossings do not require synchronizers in the destination domain, because they are held long enough to be captured by even the slowest clock domains without the risk of metastability. Traditional tools that indiscriminately define all unsynchronized crossings as CDC violations report a number of false violations based on such quasi-static signals. New tools should therefore provide a way of screening such signals from consideration. For example, users could specify which signals and paths the tool should disregard when searching for CDC violations.

Figure 6: Example of a quasi-static signal

False paths: This is another, large category of crossings that dont require synchronization. False paths are apparent crossings, detected by structural analysis, that are never activated. Take, for example, a bus driven with a CPU master and multiple IO interface slaves PCI, USB, etc. The bus arbiter is designed so that a slave can communicate with the CPU and vice-versa, but a slave cannot communicate directly with a slave. Yet CDC analysis is likely to show domain crossings between usb_ck and pci_ck and so on. Here again, users should be given the ability to point out such paths and direct the tool to exclude them from the violation list.

Example 7: Example of a CDC false path

Atrenta, Inc.

Memory cores in FIFO synchronizers: Another group of signals that do not require synchronization when crossing domains are those that read from the memory core in a FIFO synchronizer (i.e., FIFOs used specifically for synchronization). Because of the latency between writing to and reading from any given location in the core, such signals are, for all intents and purposes, quasi static and should be excluded from violation reports. Tools should ideally recognize such cores and omit them, or at minimum allow user to waive analysis in these cases. Custom synchronizers: Tools may detect commonly used synchronization structures, such as two-flop or multi-flop synchronizers. But traditional tools may fail to recognize a variety of other approaches--including custom, user-designed synchronizers. Therefore, in addition to having a large pre-defined library of standard synchronization structures, tools should allow users to specify any custom synch structures used in their design. When doing its structural analysis, the tool will then recognize these user-defined elements as valid synchronizers and not mistakenly report such crossings as unsynchronized.

Figure 8: Handling of IP blocks in CDC verification

Handshake mechanisms: Handshake protocols--which coordinate transmission between the source and destination domains--are another popular synchronization technique, but one that traditional structural analysis tools often fail to recognize. New tools are therefore needed with advanced structural analysis capable of recognizing a wide variety of handshake mechanisms. (As detailed in the next section, tools can be of even greater value if they are also able to functionally verify handshake mechanisms.)

Figure 9: Handshaking synchronization is a commonly used technique that results in numerous false violations

Detecting Problems at Synchronized Crossings

Simply synchronizing a signal does not necessarily address all potential CDC problems. There are a number of important errors that can occur at synchronized crossings, and CDC verification tools should be able to detect the following violations:

Atrenta, Inc.
Cross-domain fanouts: These are signals transmitted from one flip-flop in the source domain to multiple flop synchronizers in the destination domain. This may result in loss of signal correlation, and is therefore a bad design practice that CDC tools should flag. The correct method for handling this case is to synchronize the signal only in one place, then to fanout the signal after synchronization.

Figure 10: Fanouts into multiple clock domains

Cross-domain fanins: A cross-domain fanin occurs when two signals originating from separate source domains are combined through combinational logic in the destination domain. This scheme is glitch-prone since there is no fixed phase-relationship between the incoming signals. The correct method to handle this case is either to synchronize the signals separately before combining them in common logic. Again, tools should be able to detect and report this class of violation.

Figure 11: Fanins of multiple signals crossing clock domains can cause glitches
Reconvergence: Yet another design practice that can result in functional errors is reconvergence, where two or more signals from different domains converge on combinational logic after synchronization. Once again, loss of data correlation may result. Tools should automatically detect and flag these violations.

Atrenta, Inc.

Figure 12: CDC: Re-convergence can result in data correlation problems

Handshake violations: As described above, handshaking is a common method of synchronizing signals across domains, and tools should have the ability to recognize handshake structures. Beyond these structural capabilities, new tools can be of great benefit if they also include the ability to functionally verify the handshake (REQ-ACK) protocols. This latter, functional analysis requires assertion-based verification, preferably in the form of automatic (implicit) checks.

Figure 13: FIFOs are a good example where read and write pointers need gray code encryption
Gray code violations: When control buses cross clock domains, there is a danger that slight differences in propagation among the bus wires will cause loss of correlation in multi-bit data. To prevent this, gray coding must be used to ensure that only one bit on a multi-bit bus changes on any given clock cycle. CDC tools should therefore verify correct implementation of gray codes on all buses that cross clock domains. As with handshake protocol checking, this requires formal, assertion-based analysis. It should be done automatically, using implicit checks.

Hold time violations: In cases where a signal crosses from a faster clock domain to slower one, a pulse extender can be used to hold the signal to meet the capture time of the destination domain. CDC tools should therefore be able to 1) recognize fast-to- slow crossings and 2) apply assertion-based analysis to verify that signal hold times are adequate. All of this should be done automatically, with no need for user intervention.

Atrenta, Inc.

10

Figure 14: When signals cross from a fast to a slow clock domain, hold violations can result

Additional Tool Capabilities

Beyond the key features listed above, there are a number of additional CDC tool capabilities that are highly desirable. Tools, for example, should be able to handle any size design, up to and including those with tens of millions of gates. Mixedlanguage support is essential, because SoCs typically mix IP blocks defined in different HDLs. The tool should support of an assertion library, enabling users without extensive experience in formal verification to define their own assertions (above and beyond the implicit checks the tool performs automatically). Since in practice, its not always possible to prove all assertions in a reasonable amount of time, it is also beneficial if the CDC tool can output assertions in a form suitable for simulation. Another important capability is a fully integrated debugging environment that allows users to seamlessly cross-probe between the CDC violation list, the RTL schematic and a waveform viewer. This allows the user to quickly find the source of CDC problems. That kind of cross-probing is much easier to do when debugging is an integral part of the CDC tools, rather than a separate, third-party tool. Single tool integration also frees the user from worrying about compatibility and interoperability issues.

Atrenta, Inc.

11

Figure 15: Advanced debugging capabilities are essential for CDC verification

Conclusion
CDC verification can be greatly improved through a combination of capabilities lacking in traditional analysis tools. These capabilities include richer and more flexible structural analysis, along with functional, assertion-based analysis and integrated debugging. These features will allow new-generation tools that simultaneously minimize the false violations over-reported by traditional tools and detect the CDC violations the traditional tools miss. The potential ROI is enormous. By quickly eliminating CDC errors up front at the RTL level, enhanced CDC analysis can save companies millions of dollars in redesign and refabrication costs, cut months of development time and substantially improve the profit potential of products.

About Atrenta
Atrenta Inc. is the leading provider of early design closure solutions to radically improve design efficiency throughout the IC design flow. Customers benefit from Atrenta tools & methodologies to optimize their designs early in the RTL phase for linting, clock domain crossings (CDC), power estimation and reduction, design for test (DFT), constraints generation and validation including timing exceptions, and RTL prototyping. Atrenta optimized RTL delivers up to 30% efficiency gains in the chip integration, implementation & verification phases. Atrenta has over 130 customers, including the world's top 10 semiconductor companies. Think Early Design Closure! Think Atrenta! For further information, visit the Atrenta website at www.atrenta.com, email moreinfo@atrenta.com or call 408-453-3333.