Interview: Coverage-driven Random Verification Apurva Kalia Cadence Design Systems Interview with Apurva Kalia, Cadence: Coverage-driven Random Verification Coverage-driven random verification methods, supported in the recent Cadence® Incisive 6.2 software release, are becoming recognized as one of the best ways to verify complex IC designs. To understand how to take advantage of this solution, we talked to Apurva Kalia, VP of R&D for the Incisive product line. For the past year, he has been working on the latest technology advances in the area of coverage driven verification. cdnusers: What is happening in the industry that is creating a demand for Coverage-driven random verification techniques? Apurva: There are a couple of trends that have been prevalent over the last five years that have had a profound impact on verification. The first one is, of course, time to market. A lot of the products our customers produce are targeted toward segments such as consumer electronics, computer infrastructure, or communications—products with short turnaround times. In general, our customers are expected to come up with new versions of products in a six-month span. For verification engineers this means the time available for verifying the design is very, very short. The second trend is design complexity. Over the past five years, designs have gone from 120 nm all the way down to 65 nm and, now, to 45 nm. This means a couple of things: There is a lot more functionality on the chip that needs to be verified which is required to make the chip economically viable There are new challenges designers and engineers are facing, especially in low power and signal integrity. cdnusers: How does this release help address these technical issues? Apurva: I just talked a bit about complexity, the need to manage large amounts of verification data in a smaller amount of time. A good way to do that is to use a random and constrained-random verification approach instead of a directed testing approach. Traditionally, in verification, users write directed tests targeting very specific functionality in the chip. However, with functionality increasing, it is no longer possible to cover every scenario by writing simple directed tests. We need a methodology where users can test or validate their design in a random or constrained-random manner. But, there are challenges to this approach. If you implement a random or constrained-random approach, how do you measure the effectiveness and progress of the verification? This is really where the coverage-driven random verification solution can play a critical role. cdnusers: So, what is coverage-driven random verification? Apurva: Let me first start with a very generic definition of coverage. When we talk about coverage, we are trying to establish a measure— basically a metric of success. That is the basic principle applied in coverage-driven verification. As engineers define what they want to verify, they do not just define the functionality they want to verify but also some specific aspects that they want to cover. For example, when an engineer is testing a stack or protocol, he or she would want to identify those conditions where the stack becomes full or the stack overflows. These are what we call coverage points. These coverage points or milestones need to be closely managed and measured so that an engineer has the confidence that everything is verified prior to sign-off. Here is where the solution takes over. Incisive coverage-driven random verification capabilities help users keep track of these coverage points—whether they are being hit, how many times they are being hit, and under what conditions. It also provides feedback, so they can determine how good their verification has been, what kinds of trade-offs they will need to make going forward – especially as spec changes are introduced throughout the cycle. Of course, this is a very simplistic view of the solution because the coverage points themselves can exist at different levels of abstraction—from a basic level like code coverage to the most advanced measure of functional coverage points. However, the basic premise is the same. The users can define interesting parts and functionalities of their design, which must be verified and tested before a design can be fully signed off. cdnusers: Back to the question you posed earlier: How do you measure the effectiveness of your verification with Coverage-driven verification? Apurva: If you are using a random and constrained-random verification methodology how do you determine that your verification is really enough, how do you know you are done? Coverage-driven random verification helps users answer those questions. It provides a closed loop, a mechanism to measure the effectiveness of what you have been verifying. And, it also offers a mixed-language solution, which is important to the broader team involved in the complex design and verification process. I believe that what has happened with design entry environments will happen with verification environments as well—they will become mixed language. Therefore, new verification solutions truly need mixed language capabilities. You can have parts of your verification environment in e, parts of it in SystemVerilog, parts of it in SystemC, and they all need to work closely together. With true mixed language solutions, design teams will even have the ability to take pre-fabricated verification IP, plug it in, and it will work seamlessly. Our 6.2 release offers many benefits around testbench development that are portable across technologies and vendors. cdnusers: What results will users who adopt Coverage-driven random verification realize? Apurva: Well, certainly improved quality, which I consider to be the most important. Quality here means quality of the verification—the ability to find more bugs with more and more verification scenarios of high-quality in the same or even a lesser amount of time. In other words, when verification teams are given the same amount of time to verify much more complexity, these coverage-driving random techniques will offer the automation needed and become critical to address the volume and quality needed to keep pace. Quality will be enhanced by coverage-driven verification because we give users the ability to define coverage points and go inside the design by putting coverage triggers as deep in the design as they can. They will now have the capability to determine whether corner case scenarios (or hard to find bugs) are being hit or not. The more we can find out, the more bugs we can hit and the higher the quality of the verification. Predictability will also be enhanced with these solutions because now instead of just continuing to verify blindly with simple directed testing, users will have a much better way to measure the verification process to completion. And, of course, the time to market issues I mentioned earlier will be addressed—teams can do more verification in less time. They can now generate a far greater number of tests and far greater number of scenarios than with previous generation methodologies. And that, tied with coverage-driven verification, increases your productivity. cdnusers: Who will benefit most by deploying 6.2? Apurva: The first users to benefit will be those whose verification needs are very large—those who are doing SoC integration, who put together the entire chip and want to verify at the chip level rather than the individual block level. The second group of users who will benefit are engineers who are doing structured verification, whether at the chip level or the block level. By definition, these would be verification teams whose are addressing verification by creating structured, reusable verification environments. The third segment includes those doing block-level verification with block sizes beyond 1 million gates. They will want to move to a more methodology-oriented verification approach. cdnusers: Is there anything we haven’t asked that is important? Apurva: I would like to mention planning and management, which are important aspects of the coverage driven solutions that have been touched on but not really pointed out. Because of the complexity, planning and management of all of this data has become extremely important. Here’s a recent example. A customer design cycle was nine months. Out of that, the verification cycle was five months—more than 50% of the time was actually spent in verification. This shows how important it is to manage and plan the verification process as it has become such a huge effort and large part of the overall design cycle. By directly addressing time spent on verification with verification management and good planning, users will be able to shorten the overall verification process and gain back some of that development time. In other works design teams will be able to spend more time on differentiating their designs for market success, vs. spending time developing directed tests. Users need to consider and plan: How they will verify individual blocks? How will the verification environments be linked together into a top-level verification environment? Will everything be done through simulation alone or hardware emulation at some point? What kind of engines need to be used for verifying? All these things need to be planned out, managed and measured throughout the process so they can be executed properly. A planning and management solution that leverages coverage-driven techniques helps users plan verification tasks and manage them over a period of time providing visibility into the overall progress. This is the kind of predictability that will eventually help determine when verification is done. Summary About the author Apurva Kalia Biography Apurva Kalia is Vice President of R&D for Incisive Simulation Products at Cadence Design Systems. He has more than 18 years of industry experience, the last 10 have been spent in the domain of verification. His focus in the past year was on Coverage Driven Verification. Apurva has served on many standards and Industry committees. He works in the Cadence office in Noida, India. Ratings   This content has been rated 3.5 out of 5 by other users   Comments