Consumerism of electronic products is driving the SoC companies to tape out multiple variants of products every year. Demand for faster, low power, more functionality and interoperability is forcing the industry to come up with standard solutions for different interfaces on the SoC. In past couple of years, tens of new protocols have shown up on silicon and equal no. of protocols has been revised spreading their description to thousands of pages. Reusability is the key to conquer this level of complexity both for design and verification. The licensing models for IPs & VIPs vary and many design houses still are in the dilemma on ‘Make vs Buy’ for verification.
Points that run in favour of developing in-house VIP solutions include –
- Cost of licensing the VIP that front loads the overall design cost for a given project.
- Availability of VIP for a given HVL, methodology & simulator.
- Encrypted VIP code aggravates the debug cycle delaying already aggressive schedules.
- VIP & simulator from different vendors lead to further delay in root causing issues.
- Verification environment developed with a VIP ties you to a vendor.
- DUT specific customizations need to be developed around the VIP. Absence of adequate configurability in available solutions poses a high risk to verification.
While obvious, reasons why to procure the VIP include –
- Reusability advocates focusing on features that differentiate the final product and leave the innovation on standard solutions to relevant experts.
- Developing a VIP comes with a cost. A team needs to be identified, built and maintained all throughout with a risk that attrition would lead to risk at critical times.
- Time to market is important. Developing/upgrading in house VIP may delay the product itself.
- For new protocols or upgrades to existing ones, there would be a ramp up associated with protocol knowledge and this increases the risk with internally developed solutions.
- Probability of finding a bug and the end product being interoperable is high with third party solutions that have experienced different designs.
- Architecting a VIP is easier said than done. Absence of an architecture & process leads to multiple issues.
- In house solutions may not be reusable across product lines (different applications) or projects due to missing configurability at all levels. Remember verification is all about JUGAAD and such philosophy doesn’t work with VIP development.
- With increasing adoption of hardware acceleration/emulation for SoC verification, there is need to develop transactors to reuse VIP leading to additional effort which otherwise would be done by vendor.
- Poorly developed VIP can affect the simulator/accelerator performance badly in general and at SoC level in particular. This in turn would affect the productivity of the team. To be competitive, vendors would focus on this aspect which is otherwise missing with internal solutions.
- External solutions come with example cases and ready to use env giving a jumpstart to verification. For in-house solutions the verification team may end up experimenting to bring up the environment adding to delays.
Clearly the points in favour of BUY outweigh the BUILD ones. Infact the ecosystem around VIP is evolving where solutions are available to the issues favouring MAKE too. With standard HVLs and methodologies like UVM, simulator agnostic VIP is relatively easy to find. Multiple VIP vendors and design service providers with a VIP architecture platform are getting into co-development of VIPs to solve the problem of specific language, methodology, encryption and availability of transactors for acceleration. Customization of VIPs to address DUT specific features or enable transition from one vendor solution to another is also on the rise through such engagements.
With this, the debate within the organization needs to move from BUILD vs BUY to defining the selection criteria for COLLABORATION with vendors who can deliver the required solution with quality at desired time.
In case you still are planning to build one, drop your comments on why?
Relevant posts -