Efficient analysis of CDC violations in a million gate SoC – part 1
With the increasing complexity of SoC, multiple and independent clocks and resets are essential in the design. Here, Clock Domain Crossings (CDC) are a potential source of design errors. Hence, performing thorough CDC checks is an integral part of any SoC Verification cycle. However, running structural CDC on a million-gate SoC throws huge number of violations as the tool is looking blindly for structures wherever there is a Clock Domain Crossing. So, it is tedious to remove false violations and dig out actual functional issues (which might be very less as compared to the reported violations). Based on knowledge of clock switching, paths that are static, paths that are never functionally excited, some protocols, etc. a designer can analyze the paths and ignore the noise i.e. false violations.
This article is split into two parts. Part1 is data path and Part2 is reset path
Data path analysis
It has been a general observation that tool runtime is always a major issue while running CDC checks on a huge SoC design. One of the best ways to reduce the runtime of the tool is to know your design well, apply appropriate signal constraints to avoid seeing invalid violations altogether. For example, while doing a functional CDC analysis, it is advised to tie all the DFT (Design for Test) and self-test related signals to their functional values. As it is known that a typical CDC tool will define a new domain at every mux output (if the inputs are from separate domains), you can imagine how many paths can be made transparent if we constrain the test muxes in the design! Similarly, for DFT/self-test mode CDC analysis, constrain the signals to their test mode values.
Below, we have discussed typical SoC design scenarios where we can have CDC violations reported by tool. It is described how a designer should analyze these data paths and when he can waive them off.
CDC paths due to isolation signals
Suppose we have two IPs, IP1 and IP2 in two different power domains but with synchronous clocks. We need to have an isolation cell (say, at Clk3 – asynchronous to both the clocks) at this power domain crossing to isolate the output signals of a power-gated block during transition from one power mode to another.
The CDC tool will show a violating path from Clk3 to Clk2. However, if we are sure that the clocks to IP1 and IP2 will be stopped before the enable is toggled (which would be the usual case) and will be restored only after switching operation is complete, we can waive such violations. However, there may be cases when clock to IP2 can’t be gated. Such cases will have to be reviewed by the designer carefully.
Figure 1 CDC Violations at isolation signals
CDC violations at Inout PADS
Due to limitations on number of PADS for a chip, we multiplex different input and output signals onto Inout PADS. In the given structure (in Fig. 2), the tool will structurally identify a CDC violating path from flop of IP2 at Clk2 to flop of IP1 which is at Clk1. But this path is never functionally excited, as based on control signals only one path will be active – either from PAD to IP1, or IP2 to PAD. Hence, these false paths can be waived.
Figure 2 CDC Violations at Inout PADS
Reconverging structures
We can have functional issues at convergence of two synchronized paths. Whenever two data signals are combined after being independently synchronized, there is a potential issue as explained. For any synchronized crossing we know that a new value will be correctly captured, without metastability, on one of two successive receiving clock cycles. But there is no way of knowing on which clock cycle it will be captured. The two combining signals can be arbitrated differently and can end up being received into the destination domain on different clock cycles. However, the functionality requires them to be received in same clock cycle. But we can’t guarantee it. So we may observe some unexpected behavior.
In the case below (in Fig. 3), we can have a reconvergence issue at the output of combinational logic (out). We can ensure that the below structure causes no violation only if one or both the paths are static or toggling of both the paths is mutually exclusive.
A typical case could be where clk2 is system clock (at which register programming of IPs is done) and clk1 is baud clock of the IP. Suppose PATH B is representing output of a configuration register that is programmed initially (at system clock) for all transactions of IP later (at baud clock) and hence can be considered as a static signal afterwards. We can infer that there will be no case when both PATH A and PATH B are toggling simultaneously. So, we can safely ignore this path having reconverging structure.
Figure 3 Violations at Reconverging structures
Configuration of SoC specific logic
There is SoC specific logic (in addition to IPs) which is configured initially through software before the IPs are interacting with each other. A typical case could be as shown below (in Fig. 4). Here, we have a provision to use hardware trigger from timer module to ADC. Clocks of both the module are synchronous. However, if we don’t want to use hardware trigger and want to go only for software trigger for ADC we need to constrain the input of ADC based on configuration of mux select through general purpose register. Suppose the general purpose register is working at clk3 which is asynchronous to clk2 of ADC. The CDC tool will show a violating path from clk3 to clk2 but we can waive this path as we will program initially the select of the mux and then later we will use the ADC. So, this becomes a static signal when it is used.
Figure 4 CDC Violation at Configuration of SoC specific logic
CDC taken care via protocols
As we know an efficient CDC analysis is best done with proper design know-how. There may be a certain protocol in an IP which might ensure that certain signals flagged by the tool don’t require synchronization.
Consider a hypothetical protocol (Fig. 5) where we receive 4 frames at baud clock. The first one tells about the start of protocol (SOP). The second and third contains payload and fourth one indicates end of protocol (EOP). The detection of end of protocol generates an interrupt to the system. We need to synchronize this interrupt as our system is working on a different clock (say system clock). The received payload (at baud clock), however, may be read by the system (at system clock) without any synchronization because the system will read the payload only after the interrupt is acknowledged. So, the payload can be considered as a static data when used in other domain.
Figure 5 CDC Violations taken care via Protocols
Outputs to PADS of chip
If we have some signals going to PADS of chip (as shown in Fig. 6), then considering the PAD as a primary output the CDC tool will show violation. But there is no functional issue as such. The software will configure the control signals of IOMUX and data from flop will be launched on clk1 to GPIO PADS. It is required that the SoC designer clearly indicates to the board designer which output data signal of SoC is associated with which clock signal.
Figure 6 Outputs to PADS of chip
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
