26-04-2012, 11:49 AM
Intellectual property (IP)
Intellectual property (IP) reuse has long been touted as one of the keys to enabling today's massive SoC designs. The concept of reuse seems simple and easy in theory, but there are a number of obstacles that design and verification teams must address to be successful, especially in the case of complex commercial IP cores.
One of the first things a design team must address is evaluating if the design IP meets requirements as provided. In most cases the IP will require some level of reconfiguration or redesign.
Another challenge that must be dealt with early on is determining if the IP meets the physical requirements of the process in which it will be implemented. You must answer questions like, "Does ASIC/FPGA Vendor X have a DLL/PLL that meets the IP's functional requirement?" or "Does ASIC/FPGA Vendor X have the correct I/O Cell, Hard Macro, or PHY that this IP may require?" Another challenge is determining if the IP can be implemented within the speed, area, and power limitations of the targeted silicon technology.
After conquering the most obvious obstacles, design teams may start to feel confident that the hard part is over. Unfortunately, there are several other large and complex tasks that must be addressed to ensure successful IP integration and reuse.
The most critical of these is the functional verification of the design IP, which is usually the most underestimated task. "Why do I need to test it?" and "The IP vendor already tested it, so I don't need to test it!" are phrases often heard when this subject is first broached. Unfortunately for people striving to reuse design IP, it's not as simple as that. In reality, just as with the previous obstacles, solid engineering work must be done to understand this aspect of IP reuse and to ensure success.
Choosing a verification strategy
The process of determining the verification strategy for a piece of design IP involves a number of important steps. One of the first is to understand the IP provider's verification process and review their verification plan and efforts to date. The particular verification methodology employed by IP vendor can greatly affect the quality and reusability of the IP.
A common mistake made by design teams is to read too much into the fact that Vendor X's IP has been built in silicon by customer Y. This is certainly valuable information that can allow customers to gain confidence that IP implementation in a specific technology is viable and achievable, but it does little to address the question of whether the IP meets your current needs from a functional perspective.
In order to effectively evaluate the IP provider's verification strategy, the IP consumer must start by creating their own verification plan specific to the target application. Users need to sit down and come up with a list of important features and functions that are critical for their implementation.
It's also useful at this point to define performance metrics and goals for these metrics so that the end user can validate not only that the function of the core in their system is correct, but also that system can meet its required performance goals.
In creating any verification plan, it's very important to prioritize test plan items. Once that effort has been initially completed it becomes much more straightforward to review the provider's verification plan, and see how well it is aligned with the user goals for this usage of the IP.
Areas that are of critical importance to the end user that were not adequately covered from a functional and performance perspective constitute holes in the verification plan. These holes in the verification plan will need to be plugged by the end user to control risk and deliver successful silicon.
In my experience, most applications of complex IP only utilize a subset of the full features and functionality of the IP. It's quite unlikely, especially with complex IP, that the subset of functions used by different customers will overlap completely. Therefore, it is essential to evaluate how (or if) the specific features that are important to you were verified.
It is equally important to ensure that the IP provider has a viable process and infrastructure for changing the functional configurations of the IP, and verifying those configuration changes. Understanding the methodology used, how different configurations were tested, and what types of coverage were measured will greatly help the verification team to understand what, and how much, they need to test.
But the vendor said it was working!
Let me provide an example to illustrate this point. During one project, our team decided to use a DRAM controller from one of the top tier ASIC vendor IP libraries. Inquiries with the vendor indicated that they had over five working pieces of the silicon using this IP core in the technology we were targeting.
Good news, right? We plugged the IP into our system and I ran a simple directed random test algorithm against the core and it immediately started failing. The very first test case I wrote found five bugs in the controller.
How was this possible? The vendor said it was working in silicon! The answer lies in the configuration and functionality of the core. Upon further investigation with the vendor, we determined that in all previous uses of this DRAM controller it was connected to a CPU cache controller.
This cache controller only utilized 8 byte long reads or writes. In addition, these transactions were always 8 byte aligned. Our application and my random transaction generator was generating reads and writes with various lengths and alignments that completely broke this piece of IP.
Again, this is a true story from a real world design project. The vendor was a little dumbfounded when the issue was presented to them. I will not use any real names to protect the guilty, but unfortunately this is not an isolated incident.
This example shows why IP integrators need to form their own
verification plan based on the criteria being described here. If you take some time to evaluate the vendor test plan and methodology against your needs and expectations, identifying issues or holes similar to this can be done up front and planned for. This will help the IP evaluators assess the IP verification quality, associated risk, and help quantify the effort it will take to reach verification complete.
In my experience, the quality and robustness of commercial IP varies widely; the wide variety of techniques used for verification result in vastly different quality levels. With only one exception in the last 10 years, myself and the teams I worked closely with found extensive and critical bugs in every single commercial IP that was being reused.
Even if the IP is functionally perfect, teams still need to address how they will verify that the IP performs correctly in their system-level environment, and how they will verify their own logic that interfaces to the IP core. Don't assume that just because you believe the core to be functionally correct that the IP will achieve the desired function and performance within the context of the target system.
The importance of verification IP
Good quality Verification Intellectual Property (VIP) can offer tremendous value to teams trying to integrate a commercial IP core into their device, regardless of whether teams are testing for compliance or just testing the integration of the core into the target system. In the recent past, commercial VIP often only consisted of a bus-functional model (BFM), and may have included a monitor to do some protocol checking. For VIP to be effective in enabling reuse of complex design IP, it needs to provide many more features and functions than just a BFM.
More modern commercial VIP offerings tend to be highly reconfigurable, and offer more robust verification functionality such as directed random stimulus generation, protocol and temporal checking, functional coverage metrics, and reusable stimulus libraries (scenarios). The concept of highly reconfigurable VIP stems from the nature of the highly configurable IP that people are trying to test. If the VIP cannot be reconfigured to match the ever-changing design IP, then it clearly will not be of much value in verifying configurable IP.