Ramesh is VP of Product Strategy at Real Intent. He brings 25+ years of experience in engineering, customer management, product management and marketing to Real Intent. Prior to joining Real Intent, he led the product marketing of the core product suite related to RTL design at Atrenta. Previously, … More »
Gigagate SoC Designs and IP Growth Challenge Verification
May 15th, 2014 by Ramesh Dewangan
In my last article, Redefining chip complexity, I touched on the challenge of using asynchronous interfaces for the integration of the various IPs in SoC design. In this posting I, want to drill down to expose more of the verification issues and to suggest the right approach to handle them.
Asynchronous clock domain crossing and the associated meta-stability issues are a well-researched problem. There are multiple verification solutions in the market and they do a fair job of reporting issues and pin-pointing what you can do next. So what’s new?
The asynchronous challenge has acquired additional dimensions.
First and foremost is the SoC’s continue to get enormous in size and complexity. In Dave Bursky’s article in Chip Design Magazine, Advances in IC development take center-stage at ISSCC, the “advances in transistor integration since the early 1990s have led to logic chip densities crossing the 1 billion device mark in recent years and processors containing over 2 billion transistors are now shipping. Further integration will push densities to 2.75 billion transistors with IBM’s disclosure of its latest six-core processor with on-chip embedded DRAM.” See Figure 1.
This demands a new level of performance and capacity in the verification tool to meet the asynchronous challenge. The traditional domain crossing solutions that were originally developed 10 or more years ago are beginning to fail. A new verification software infrastructure is needed with new data models to improve capacity and the use of multi-processing in the analysis engines to improve performance.
The next dimension of the challenge is the ever-growing breadth of issues. You have significantly more design aspects that need to be analyzed for asynchronous implications due to evolving design methodologies. You need to look at not only clocks but also resets. You need to account for the soft-resets, configuration registers, constant nets, and so on. You need to not only worry about the metastability issue, but now glitch potential, low power implementation changes, data correlation issues (due to asynchronous clock convergence or divergences) or not having enough pulse width when crossing domains. The article CDC Verification of Fast-to-Slow Clocks gives a more in-depth review of one such issue.
The third dimension of the challenge is significantly high degree of re-use and integration of multiple IPs in today’s SoC. In the ARM Community blog, Today’s Software Design Trend: More Acquiring IP Than Making IP, the percentage of design reuse in a typical SoC has crossed 50% already. See Figure 2.
Specific to asynchronous challenge, the problem boils down to how do we reuse the asynchronous domain crossing verification that was performed on a block or IP when the verification process moves to the SoC level? The solution demands a comprehensive hierarchical methodology, which does not miss even a single asynchronous functional bug.
Now that we have seen some of the challenges, let us look at the solution that is needed.
Don’t we have multiple tools in the market for CDC (clock domain crossing) analysis? Sure we do.
Do they meet all the challenges described above? Unfortunately, no.
For the size and complexity challenge, you need a tool that is designed ground up for the performance and capacity.
This reminds me of an effort from an earlier part of my career. At the large semiconductor company I worked at, we tried to create a chip level STA solution using DesignTime (the static timing analysis engine of Synopsys Design Compiler). Of course, we failed. DesignTime was designed to run incrementally with a small set of objects. Ultimately, we went with Mentor CPF (critical path finder) which was designed to be a chip level tool.
Similarly, many of the current domain crossing verification tools are designed to run at the block level and are being retro-fitted to run at SoC level through complicated methodologies.
For the breadth of asynchronous design issues, again, the current solutions are primarily designed to resolve metastability issues due to asynchronous clock domain crossing paths. They are being haphazardly extended to cover additional aspects like glitch analysis or re-convergence. Because of the accretive approach, tool users suffer from over-sized reports and noisy results. The effort users have to put in to sort out meaningful violations from a debug report is like finding the proverbial needle in a hay stack.
For SoC hierarchical verification, the new solution is emerging. The current tools either run flat at SoC level with waivers for the domain crossing issues inside the IP, or create an abstraction of the verified blocks and use that at SoC level rather than the full RTL description. Unfortunately, neither approach fully meets the needs of design teams. The first approach is not scalable for the sizes of todays’ SoC. The second way has potential to miss CDC bugs at SoC level as the abstraction cannot fully represent the inner workings of the blocks. What you need a smart hierarchical methodology that will scale and not miss any bug.
What the designers need is a solution that meets all the dimensions of asynchronous challenges. I invite everyone to come to the Real Intent booth, #1825, at the Design Automation Conference in San Francisco, June 2-4 to see the next generation of CDC verification.