Atul Bhatia, Director, nSys Design SystemsIndependent Interpretation
The most important benefit of buying the VIP rather than making it is that a commercial VIP provides a totally independent, clear and unambiguous interpretation of the specifications of a protocol for which it is designed. Until the time when the specifications themselves are written such that they have no ambiguity, this independent interpretation is invaluable. It gets even more important when the specifications are those of a complex protocol. In case the commercial VIP is already proven by use with RTL designs of other users, the value increases to several times of its cost to the user. This is because the user is assured inter-operability and compliance due to the use of this VIP with other designs.
Availability of Test Suites
If the VIP is available not only with the Bus Function Models, Monitor and Protocol Checker but also with Test Suites, then the user is able to save considerable time that would have been spent in writing the test cases that are available as part of the Test Suites. Not only are the test cases difficult to identify and time-consuming, most engineers write them grudgingly. Availability of test cases in source code makes it easier to modify and create additional cases unique to the user’s designs.
Just as a home-made dish cannot be packaged as attractively as the one that is available from a restaurant, an in-house VIP will also not be packaged as well as a commercial VIP. Some of the distinct features of the packaging that are very difficult to incorporate in an in-house VIP are: availability of a well-documented User Manual, Flash-based tutorials, comprehensive FAQs based upon queries faced by existing users, a self-service bug tracking portal, Application notes and a well designed GUI. In case the VIP provider is offering a family of VIPs, the additional features of packaging would be: consistency of interface, installation, operation, and documentation across the VIP family. Since the APIs for a family would be well thought out and consistent across the family of VIP, it would reduce the requirement of learning the API while using additional interfaces.
At the other end of the spectrum of the develop-or-buy decision are the FPGA developers who do not even consider using simulation for verification. They feel that they would find the bugs at the system level in any case and the bug would just require a change in the RTL rather than throw away the chip as would be the case for an ASIC developer. This belittles the complexity of FPGA designs brought about by increase in their size. Fortunately, FPGA developers are becoming aware of this and have begun verifying their designs extensively in simulation too. Especially since it is very easy to compute that the cost of a license of a commercial VIP may be less than the cost of one engineering man-month. We have not factored in the impact of the cost of delay in product which will be many times this cost.
One of the ways of overcoming the well known productivity gap is the use of Design or RTL IP. A 2002 study by Collett International Research revealed that 14 percent of all chips that failed had bugs in reused components or imported IP. The other key problem while using an IP is that its integration with rest of the design has to be thoroughly tested. Thus a VIP should be able to verify the IP at the block level and also provide features for System level verification to ensure the correctness of integration of the IP with rest of the design.
Some situations when the develop-or-buy decisions get difficult to make are when an RTL IP has been used for a while and can be expected to be bug-free or when an RTL IP is available with a VIP. It has been observed that even if an RTL IP is field-proven, it may still have several bugs that are brought out by a new design (as luck would have it). A free VIP that may be available with RTL IP unless it is from a 3rd party vendor is not good enough for use in a commercial project. In the case when a 3rd party VIP is available bundled with the IP, it is likely to have a reduced feature set sufficient to demonstrate the working of the IP and the VIP while the features required to perform verification of the IP as well as its integration with the rest of the design may not be available. In fact, the extra effort spent in using the free or scaled-down VIP is several times the cost of a good 3rd party full feature VIP.
Verification productivity that is required to meet the challenges of tomorrow can only be met by incorporating widely used and proven VIPs in the verification flow. A family of VIPs having consistency of interface as well as look and feel increases this productivity across projects. The case for developing a VIP can only be made for proprietary interfaces. For all other interfaces, it is better to buy rather than develop a VIP.