Techniques for CDC Verification of an SoC

Ankush Sethi, Freescale Semiconductor India Pvt Ltd

1. Introduction

With the increasing complexity of SoC, multiple and independent clocks are essential in the design. Hence CDC verification becomes an integral part of any SoC design cycle. A typical SoC consists of several IPs (each with its own set of clocks) stitched together. This leads to several new paths at SoC which are not anticipated at IP level. Due to huge design size, multiple asynchronous domains, Third Party and Legacy IP reuse etc.. it becomes important to devise a methodology for an SoC that can be most optimal in terms of number of violations and run time . This paper discusses several approaches for CDC verification of an SoC.

2. Different Approaches for CDC Verification

2.1 Flat SoC Verification

This has been the conventional approach of running CDC on any design. In this scheme, we give constraints and run on the whole design as one entity. It is same as running CDC on any small design or an IP. We define clocks and resets at the output of central clock and reset generator modules. The tool is able to propagate them across IPs. We just need to review any unconstrained clock or reset afterwards. So the setup in this case is quite easy as top level constraints are easily available. We can save on setup time in this case.

This type of CDC verification however can be performed only when whole of the design is available and well integrated. In this case we may find any critical bug very late in the design cycle as we are waiting for well integrated SoC to begin the setup and analysis. Here we get both Intra and Inter IP violations. We need to analyze both of these kinds of violations. It is difficult to scale such kind of scheme for large SoCs because of huge number of violations and huge run time.

2.2 IP Black boxing Flow

In this flow, certain IP(s) may be black boxed for CDC analysis at SoC. By black boxing we save on run time considerably as the whole IP is not synthesized and analyzed for CDC. This can be done selectively for bulky IPs. Here we will not get any Inter and Intra IP violations for the IP(s) black boxed. It must however be ensured that block level CDC is run on all such IPs. Also it becomes responsibility of the SoC integrator to review the clock domain associated with each port while integrating such IPs at SoC.

2.3 IP Gray boxing Flow

For a large SoC, this kind of flow is developed assuming that the IPs delivered to the SoC are CDC clean. Here we achieve gray boxing for the IPs as far as CDC is concerned. We check only Inter IP violations and not those that are totally within an IP. This kind of scheme can be leveraged for legacy and third party IPs where CDC clean behavior is expected. Consider the case shown below (Fig 1), where we have interaction between two IPs. We have two CDC paths, Path1 which is Intra IP1 and Path2 which is between IP1 and IP2. While analysis at SoC we instruct the tool not to perform any CDC analysis for paths which are Intra IP and report only those paths which are Inter IP. So for the below case only Path 2 is reported and Path 1 is not reported. The setup in this case is same as for flat SoC verification. Here also the clocks and resets are defined at top level. So we get the inherent benefit of reduced setup time. We also benefit considerably here in terms of run time as no analysis in performed inside IPs.

There is one limitation here that if any qualifier (explained below) is generated from one IP and is used outside it then that particular qualifier may not be recognized by the tool as a valid qualifier. So any valid CDC crossing using that qualifier will not be considered as CDC pass by the tool. A qualifier is a signal that controls/qualifies a crossing. e.g. select of mux in a mux based synchronizer as it governs the crossing. We can overcome this shortcoming in two ways:

• Generate such list of qualifiers (from tool) by giving initial run on flat design (without IP gray boxing) and give this information to the tool for all sub sequent runs using IP gray boxing scheme.
• Make two parallel runs one using flat SoC verification and the other using IP gray boxing approach. Then apply waivers to remove all Intra IP violations as post processing for the flat verification run. Now the two runs become comparable as both contain only Inter IP violations. The only difference they have now is the extra violations in IP gray boxing run due to certain qualifiers which were not recognized. We should filter out these additional violations and add them as waivers (post processing) for all the sub sequent IP gray boxing approach runs.

Fig 1 IP Gray boxing Flow

There is one inherent disadvantage of this scheme. Suppose we got an IP which was CDC clean and expects two synchronous clocks at its input. Now consider a case where we have connected asynchronous clocks by mistake on that IP at SoC level. There would be no synchronizers present in the IP as it was expecting synchronous clocks. The tool will flag the violations in the IP if we run on flat design (without IP gray boxing) as we had connected asynchronous clocks and there were no synchronizers in place. These violations will give us an indication that there is something wrong in either the IP or SoC . However if we use IP Gray boxing flow then we will not get these violations (as they are Intra IP) and hence miss an issue related to SoC connectivity .

To cater to the above issue, one variant of IP Gray boxing flow can be used where we ask the tool to perform analysis of both Intra and Inter IP paths. Since the IPs are CDC clean we ask for IP CDC waivers from respective IP owners. We apply these IP waivers on SoC CDC run as post processing. The application of waivers for Intra IP paths ensures that we are left with only Inter IP paths. Here any unexpected violations for an IP due to wrong SoC connectivity will be flagged as they will not be in the waivers of IP. The run time will increase as compared to IP Gray boxing flow as we are doing Intra IP analysis. But in a normal scenario we will be analyzing only Inter IP violations.

2.4 Hierarchical Bottom up Flow

In this approach, each block/IP is verified individually first and then the verification is scaled to the whole system. This kind of scheme is helpful where several new IPs are being designed for an SoC . Many other functions like Synthesis, Static Timing Analysis use hierarchical methodology for sign off. In this flow, we develop clock and reset constraints at block level for every IP individually and verify them in a standalone environment. This ensures that we are not waiting for a well integrated design to begin with as in flat SoC verification scheme. So we can reduce the risks of finding any critical bugs late in the design cycle.

One of the important steps in this approach is the validation of compatibility of IP level and SoC level constraints. This ensures that we catch any SoC connectivity issue, like the case described above as inherent disadvantage of the IP Gray boxing flow, upfront. In this flow we perform the CDC analysis on an IP and generate its abstract model. These abstract models contain clock domain information for ports of an IP. We then integrate all of these abstract models along with any SoC glue logic and check for any Inter IP violations. We save on run time considerably here as we are not reading and synthesizing the blocks/IPs but using only their abstract models. This kind of approach is useful for any design with huge gate count. This scheme also helps in reuse of IP abstract model for multiple SoCs.

2.5 Hierarchical Top Down Flow

In this top down flow the SoC owner drives the CDC verification. We develop constraints at top level and propagate them to the blocks/IPs. This ensures that all the requirements given from the top are met at the block level. This scheme eliminates the extra step of validation of compatibility of IP level and SoC level constraints as the former is generated from latter only. It is used in cases where early availability of constraints for the SoC can be leveraged for effective top down CDC verification.

Firstly, we clean the IPs from the constraints transferred from the top level environment. In this scheme while working on an IP in a standalone environment we can catch Inter IP CDC issues as explained. Consider the case shown below (Fig 2) , here if a top signal (here “out” ) in a given domain (here clk1) will feed into an IP , then it becomes the destination IP owner’s responsibility to ensure that it is used in the same domain or they must synchronize it to the domain (here clk2) in which it will be used.

Once the IPs are cleaned we then integrate all of these abstract models along with any SoC glue logic and check for remaining violations.

Fig 2 Hierarchical Top Down Flow

3 Conclusion

With the increasing design size and complexity the conventional CDC flow i.e Flat SoC verification may not be the best option due to huge run time and requirement of well integrated design to start with. This paper discusses various techniques/flows that can be adopted to perform CDC analysis of an SoC. Also the advantages and disadvantages of each scheme is discussed.

Ankush Sethi is a member of the SoC architecture and front end integration team at Freescale India. He received his Bachelors degree in Engineering (in Electronics & Communication division) in 2012 from Netaji Subhas Institute of Technology (NSIT), affiliated with the University of Delhi in India. He joined Freescale in June 2012 directly upon graduation.