The blindside blitz. The quarterback’s greatest fear. The big hit that arrives with no warning and the cover bypassed. In SoC design, particularly in clock domain crossing (CDC) analysis, RTL designers can also believe they are safeguarded from CDC glitches in their gate-level netlists. They rely on a defensive combination of RTL design style, functional verification, gate-level simulations and logical equivalency checking. And that’s right about when they get blindsided by a glitch.

Glitches in synchronous paths are momentary and mostly harmless. They do not last long enough to meet the setup-hold requirement of the next active synchronous clock edge, and static timing analysis ensures that they are not captured erroneously.

However, glitches in asynchronous CDC paths are oblivious to the arrival of the receiving clock edge. They can get captured erroneously and cause functional errors downstream. These glitch issues are extremely hard and time-consuming to debug, and are becoming increasingly expensive to fix. You need to identify, isolate and address them as early as possible.

Designers have several precautionary options when writing RTL to avoid glitches on CDC-related control, data and clock paths.

Avoiding combinational logic on a control path crossing prevents a glitch from being generated and subsequently captured in the receive domain.

Data crossings are safe from glitches as long as a synchronized control signal can block the propagation of the glitch into the receive domain.

Glitches on clock paths can be avoided by using proper clock-gating circuitry and minimal controlling logic.

But, even when designers handoff such carefully crafted RTL to synthesis, a distinct possibility exists that the synthesis tool could churn out a gate-level netlist that suffers from glitches.

Mainstream synthesis

The primary goal of contemporary synthesis tools is to generate a netlist design that meets a target specification based on three metrics - performance, area and power - while maintaining logical equivalence to the original RTL design. However, these tools do not guarantee glitch-free logic and that makes the gate-level netlists they produce susceptible to glitches.

Moreover, synthesis tools can move logic across registers (an optimization technique called ‘register retiming’) to meet performance targets in the synchronous parts of the design.

Combined, these two factors give us a recipe for introducing glitches in asynchronous clock domain crossings in the gate-level netlist, even when none was present in the original RTL design.

It is important to emphasize that these glitches are not present in the original RTL description and that they get introduced during the synthesis process. This is why running glitch analysis on a gate-level netlist is of paramount importance.

Comparison of RTL and synthesized netlist

To help illustrate how synthesis transformations can introduce glitches, consider the schematics for the RTL description and the synthesized netlist implementation of a CDC crossing shown in Figures 1 and 2.

The data signals, ‘Data A’ and ‘Data B’, are combined and being transferred between asynchronous clock domains clocked by, respectively, signals ‘Clk1’ and ‘Clk2’. The loading of the data in the receiving clock domain is controlled by a synchronized control signal, ‘CNTL’. The AND gate and the multiplexer (shown in a shaded oval in Figure 1) in the RTL description are replaced with the AND-OR circuit (shown again in a shaded oval, now in Figure 2) in the gate-level netlist by a synthesis tool. The exercise of checking that the two circuits are indeed logically equivalent is left to the reader.

Standard CDC design practices state that the data signal being transferred across clock domains is allowed to glitch as long as there is a provision to block the glitch from propagating to the receiving clock domain. This guideline is followed in the RTL schematic and a synchronized control signal gates the propagation of the data signal via the multiplexer.

However, in the logically equivalent netlist implementation, there is a term (the three-input AND gate at the top of Figure 2) that is not gated by the control signal. Hence, a glitch created in that part of the circuit can be propagated and captured in the receive domain in the next cycle. This violates the multicycle nature of the datapath and causes functional errors as the logic in the receive domain is not expecting the data signal to change.

Traditional verification cannot identify such glitches when they are introduced into a gate-level netlist. Functional pre-synthesis zero-delay simulations do not catch glitch issues and logical equivalency checking will declare the RTL design and the gate-level netlist to be equivalent. Since the number of gate-level simulations run is typically a small subset of the pre-synthesis simulations, it is quite possible that the glitch traversal path does not get sensitized by the input vectors in the gate-level netlist simulations and the glitch continues to lurk undetected.

Augmenting glitch detection

This is where the data glitch detection capability of Real Intent’s Meridian CDC 4.0 software comes into play. It systematically identifies all crossings with glitch potential through structural analysis and follows up with formal analysis to confirm the existence of a glitch. Formal techniques with their mathematically exhaustive proofs can ascertain the existence of a glitch without the need for input vectors and thus obviate the need for gate-level simulations for glitch detection.

The screenshot of the Meridian CDC Debug GUI in Figure 3 shows that the RTL version of the CDC crossing does not suffer from a data glitch issue. This is because a synchronized control signal is gating the propagation of the glitch as pointed out by the annotation.

The screenshot in Figure 4 shows how the glitch failure on the datapath is reported for the netlist version of the CDC crossing. The annotations point to the uncontrolled AND gate through which the glitch can propagate and be captured in the receive domain.

Where a glitch could occur, the tool identifies the signals involved in its creation along with their values and transitions. It also identifies the scenario which allows the glitch to propagate to the receive domain. Determining the prevailing conditions that can cause a glitch gives designers an understanding of which RTL design styles are susceptible to a glitchy implementation by their synthesis tool. Such styles can then be avoided and alternative implementations used.

The example above showed how a synthesis transformation can introduce a glitch in the datapath [1]. Glitches can also be introduced in the clock path, specifically in the logic controlling the enable to the clock gating cell. This can happen either during synthesis of a design which contained clock gating constructs in the original RTL description, or during automatic clock gating insertion by the synthesis tool for power optimization.

Meridian CDC 4.0 covers the spectrum of glitches on control, data and clock paths with a its own blend of structural and formal analysis engines. Given the short design cycles and sky-rocketing complexity of today’s SoCs, it is imperative that a CDC tool to be able to run at the RT level and netlist level and provide comprehensive detection of glitches. This enables complete CDC signoff from RTL to netlist and protects designers from being blindsided by a glitch.