Among the many verification challenges confronting system-on-chip (SOC) designers these days, clock domain crossings (CDCs) rank near the top in difficulty. The latest SOCs may have dozens or even thousands of clock domains, many of them difficult to verify using conventional tools such as simulation. Detecting these bugs using traditional simulation tools requires long simulation runs and a chance encounter. As a consequence, CDCs have become a leading cause of design errors. Such errors can add significant time and expense to the design-and-debug cycle, and may even find their way into silicon, necessitating costly re-spins.
Two particularly troublesome CDC-related issues involve FIFO- and handshake-based synchronization mechanisms. Both can be difficult or impossible to accurately verify using simulation. And conventional static CDC analysis tools do too little and too much at the same time, simultaneously overlooking realdesign errors and over-reporting large numbers of falseviolations. As a result the user is forced into an endless bug-hunting process, which often discourages the designer and leaves the real bugs undetected.
The success of static CDC verification tools is determined by two critical measures--the time taken to signoff and the completeness of CDC verification. Conventional CDC analysis tools fall short in both areas. They generate large amounts of noise (false violations)--extending the verification cycle--and provide poor coverage of complex CDC synchronization schemes.
Fortunately, a new class of CDC tool, using static analysis techniques, offers an effective automated solution to these problems. Such tools combine functional and structural analysis to both identify and verify FIFO and handshake synchronizers, while weeding out the false violations that plague traditional CDC tools.
Separating True From False Violations
In order to isolate real clock domain crossing issues, it is necessary to detect various synchronization schemes--not just basic two-flop or multi-flop synchronizers, but more complex mechanisms, such as handshakes and FIFO-based schemes. Once detected, these synchronizers need to be verified as working correctly.
Both detection and verification have their own set of challenges, but when they are done properly, one can confidently claim correctness of these clock domain crossings. This knowledge, in turn, can be used to filter out false violations, which typically result when a tool fails to recognize properly synchronized crossings and instead reports them as unsynchronized. Many tools lack the ability to detect, much less functionally verify, handshake structures. Given that it is now commonplace to find up to 80 percent of CDCs controlled by handshakes in large design modules, the false violations can be plentiful, numbering in the hundreds. They may number in the many hundreds. No wonder designers complain about false violations & handshakes! Similar problems arise with FIFO synchronizers.
1. Typical handshake structure can generate false CDC violations
Handshake synchronizers rely on request-acknowledge protocols (Fig.1).
A request signal is sent from the source domain when the data is stable. The destination domain waits for the request signal to capture the data, then sends back an acknowledge signal to the source domain. The source domain can now de-assert the request and prepare for the next data transfer.
The control, request and acknowledge signals may be synchronized using standard dual-rank synchronizers. However, since the protocol requires the request to be high until an acknowledge signal is received, the designer may determine that the crossing is safe and that no synchronization of REQ-ACK signals is necessary. Traditional CDC tools that look only for a double-flop synchronizer in such cases will report these crossings as unsynchronized, resulting in a large number of false violations. These false violations, in turn, will be embedded in a long list of unsynchronized crossings, and it becomes a tedious process to go through and identify the buses that are properly synchronized using a handshake synchronizer.
Is there a better solution? Yes: automatic identification and verification of handshake schemes can eliminate a large number of false violations. This requires several capabilities:
- Handshake recognition: In order to correctly recognize a handshake scheme, the data transfer and all components of the handshake need to be identified. Identification includes crossing detection, MUX or flop enable detection, source and destination controller identification and finally request and acknowledge recognition. Due to the variety of handshaking design styles, detection of all the components requires thorough and flexible structural and functional analysis of a design.
- Handshake verification: The crossing cannot be considered safe until its functionality is proven to be correct. Two aspects of handshake functionality can be verified (Fig. 2)
2. Functional issues may violate Handshake protocol
- Request and acknowledge behavior: Each request should result in an acknowledge within some time frame. The time frame can be detected during the handshake recognition and designer may be prompted to verify the correctness before actual verification. In addition, request and acknowledge signals may be active low or high, which can also be analyzed during handshake detection.
- Data capture window check: Data should be stable at the time a request is sent and should not change until acknowledge is asserted and request is taken off. Although this requirement verifies the correctness at the source and is not directly related to a crossing problem, a violation indicates a serious functional problem in a design.
Static verification techniques are the ideal way to perform the above verification exhaustively; Alternatively, verification can be carried out using simulation and a user-defined testbench. The difference is that the simulation approach requires a great deal of manual effort and will not exhaustively verify these schemes, leaving many bugs unresolved.