Reducing false errors in clock-domain crossing analysis

Checking for correct synchronization usually is a time-consuming, manual design process. Often, many possible problems with clock domain crossings (CDCs) are overlooked, resulting in major downstream design problems.

A number of tools have come on the market to identify problems with CDCs. Unfortunately, these tools frequently report hundreds of apparent problems, many of which are often spurious. And this is for structural CDC analysis alone. If you want to check more deeply, assertions must be added to the design. At that point, the number of false errors multiplies, as does the time it takes to go through these and find the real problem spots.

There is a way to make this process less painful. It requires a clear discipline for synchronization and a CDC analysis methodology that works smoothly with inevitable ECOs (engineering change orders) in the design. Also, your CDC tools must support methods to easily reject false negatives and support waiver techniques which do not need to be re-generated on each design ECO.

Synchronization discipline

A challenge in synchronization is that there are so many ways to do it. While each approach has advantages, the ad hoc use of different techniques within a design — and within a design organization — complicates the process of review.

No tool today can make CDC verification completely push-button. Some level of design wisdom is always required to interpret results and consider system-level implications. Having to make those judgments on a wide variety of synchronization techniques will unnecessarily complicate the review process.

Many successful companies have recognized this and have simply mandated that synchronization must be performed through pre-designed cells or by using a small set of pre-approved techniques. While this may limit creative freedom slightly, confidence gained in the quality of synchronization more than compensates for that loss.

The techniques that should be pre-approved depend on the range of applications they must support. As the most disciplined level, one can mandate that all synchronization take place through pre-defined synchronization cells.

The most common synchronization cells support single bit, general bus and fast-to-slow data synchronization. A more relaxed approach allows this logic to be hand-crafted but still requires the inserted logic be drawn from a limited set of styles. It is often necessary in the latter case to be able to add variants — synchronous reset for the synchronizer or half-cycle shifts to reduce the probability of meta-stability or data loss. Figures 1a and 1b show two common synchronization techniques.

Figure 1a — Single-bit metastability sync

Figure 1b — Multi-bit sync

In picking a CDC tool, it is important to make sure the tool supports all of the techniques needed in the design. More sophisticated tools allow the designer to define a methodology based on a wide variety of synchronization styles, including the most common techniques, user-named synchronization cells and user-defined structures, which will be pattern matched against domain-crossing structures.

False domain crossings

Often many clock domain crossings are caused by reset or configuration signals (see Figure 2). While synchronization problems can technically occur on these quasi-static signals, it will be a one-time event, and since the signals are effectively static thereafter, they can be effectively ignored for most of the up-time of the device.

The best way to eliminate these false paths is to use the same technique used in synthesis or static timing analysis — declare false paths. Your CDC tool may indicate, for example, that rst_n contributes to over 50% of the crossings and config[0] and config[1] contribute to another 25%. If you don't want to look at these cases, you can easily suppress them through false-path constraints:

cdc_false_path—from rst_n
cdc_false_path—from config[*]

Consider, for example, a bus driven with a CPU master and multiple I/O interface slaves such as PCI or USB. The bus arbiter is designed so a slave can communicate with the CPU and vise versa, but a slave cannot communicate directly with a slave. However, CDC analysis is likely to show domain crossings between usb_ck and pci_ck and so on. Again, these can easily be rejected by using false path constraints:

cdc_false_path—from use_ck—to pci_ck
cdc_false_path—from pci_ck—to usb_ck

cdc_false_path—from (state)-through (thru-point)-to (end)

Figure 2 — Examples of false clock domain crossings

FIFO synchronization

Another interesting source of false domain crossings can be an inferred memory in a FIFO synchronizer. It is common practice to gray-code the read and write pointers before synchronizing each into the opposite domain, for comparison and generation of full and empty flags. A subtle and rarely mentioned false crossing problem can occur around the read-data signal. Think about how this would typically be described in RTL:

always @(posedge write_clk)
if (write_en == 1'b1) mem[write_addr] <= write_data;


always @(posedge read_clk)
if (read_en == 1'b1) read_data <= mem[read_addr];

In fact, this domain crossing is spurious, for an interesting reason. While it is theoretically possible that a read can be made from the same address as a write (at the same time), most synchronizer designs will enforce some latency between read and write, ensuring write and read of the same address can never happen in the same cycle (of either clock). This latency ensures that the read data is, at least for a couple of cycles, effectively quasi-static and therefore cannot be a domain crossing.

A good CDC tool can automatically detect and reject these cases.

Handshake synchronization

A very common and robust method for synchronizing multiple data signals is a handshake technique as shown in Figure 3. This is popular because the handshake technique can easily manage changes in clock frequencies, while minimizing latency at the crossing. However, handshake logic is significantly more complex than standard synchronization structures and is not automatically recognized by most tools. Conventional implicit CDC analysis will report unsynchronized domain crossings at all of the crossing data signals in these cases.

Various formal tools have properties (assertions) to check characteristics of handshake structure — for instance, REQ must not be de-asserted before destination registers have completed the capture of the data. But all of these techniques require the designer to manually identify handshakes and insert those assertions for each such structure.

While there is a benefit in checking these properties, this still leaves the designer with the primary burden of ensuring that all handshakes have indeed been analyzed. Again, these structures will lead to false CC reports, which can only be eliminated by manual inspection.

Some of the newest CDC tools can automatically detect a wide class of handshake structures, significantly reducing false negatives in CDC reports. This also allows the tool to make functional analysis of handshake structures and implicit check, completely removing the need for the designer to define and insert these checks.

Third-party IP

Almost all designs today contain some external intellectual property (IP), whether internally developed or commercially acquired. For such IP as shown in Figure 4, apart from an incoming inspection check, there is little value in repeatedly checking internal domain crossings and synchronization techniques. In most cases you cannot change the internals of the IP, so any reported issues are just additional noise. Much more important is to analyze CDCs around that IP and in the rest of the design, where interaction between IP domains and design domains may lead to new problems.

Some CDC tools provide a constraint to mask all domain crossing reports internal to specified IP, while still reporting crossing between other logic and those IPs. This makes checking much easier and more efficient.

Figure 4 — IP block related clock domain crossings

Review and ECO analysis

Even when all of these spurious sources have been eliminated, a large number of potentially unsynchronized domain crossings may need to be examined. These may arise from signals that are not quasi-static in the reset or configuration signal sense, but which are known to be stable for a "sufficiently long time" before being used.

Once such a case has been examined and approved, it should not be necessary to look at it again unless you choose to. A practical method for dealing with these cases is a waiver, applied either inside the RTL code or externally, to flag that the case has been examined and approved.

An easy-to-use and flexible point-and-click waiver methodology, as shown in Figure 5, is preferable to "officially waive" one or more violations of any type. These waivers should be applied intelligently, adapting to changes to RTL code and therefore they should rarely need to be updated. Where needed, these waivers and the CDCs they suppress can still be analyzed for the purposes of a design review or a final pass to re-validate all domain crossings.

Figure 5 — A point-and-click methodology for waiving violations

Functional analysis

Functional analysis of CDCs is a natural extension to structural analysis. Each identified synchronization structure carries with it one or more functional requirements. For example, consider a common mux re-circulation synchronizer, shown in Figure 6.

Figure 6 — A common mux re-circulation synchronizer

The mux drives a register in the destination domain and allows data to pass from the source domain only when selected, otherwise the mux recirculates the register output value. The select "sel" must be synchronized to the designation domain.

So far this is a structural check. The functional check required in this case is that the source data signal "data" be stable when the select "sel" goes high. Since the select and data signals are automatically identified, this should be an automatic check.

Other checks in this class include fast-to-slow domain crossing hold-time, gray-encoding checks, handshake checks and more. These checks will not reduce, and may increase, the number of issues reported, but do so on a solid foundation of accurate structural identification, greatly reducing the chance of false positives.

Summary

CDC analysis has proven value but can be viewed as a high noise, low signal form of analysis. Following these proven techniques can help avoid the frustration in combing through page after page of false negatives and greatly increase the likelihood of finding real problems.

Bernard Murphy is chief technology officer at Atrenta Inc. Murphy has nearly 20 years experience in design, sales, marketing and business development. He previously held senior positions with Cadence Design Systems, National Semiconductor and Fairchild.