Verification IP : Build vs Buy?

[gauravjalan]

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.

Why BUILD?

Points that run in favour of developing in-house VIP solutions include –

ost 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.

Why BUY?

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 -
Verification IP : Changing landscape - Part 1
Verification IP : Changing landscape - Part 2
Choosing the right VIP

<script src="//platform.linkedin.com/in.js" type="text/javascript">
lang: en_US
</script>
<script type="IN/Share" data-counter="right"></script>

 

[Daniel Payne]

You've made a compelling case for buying the Verification IP over building it. Let's see who can justify the case for building their own VIP.

 

[gauravjalan]

I doubt that Dan

 

[fabien.journet]

Hello Gauravjalan,

I am not able to build a case on building VIP, but I am thinking of a parallel topic:

There is 2 types of license for ARM users: somewhat either "just use the official ARM processor" or an architecture license where ARM customer are able to tune architecture for themselves. I know that only 3 company use this second one: Qualcomm, Apple, and I forgot the last one (or are there 4 of them?) Basically the successful company do lots of stuff on their own!
But that also means one needs a scale big enough to afford it.

Anyway, I tend to agree on this buy vs build:
If one decides to buy an IP, one already choose not to differentiate on it, vs competition, so there is no point spending tremendous effort on its verification, and even if a bug is detected, the vendor has to correct it, for everyone, one still does not bring added value vs competition.)
If one decides to differentiate on an IP design, thus build its own version, having a "quite standardized VIP" should be much more efficient for the IP verification.
For me building VIP makes sense when one is "inventing the wheel" in the race with the rest of the industry, i.e. when vendor solution are not mature yet...
I see no real point doing it to re-invent the wheel.

 

[gauravjalan]

Hi Fabien Journet,

"For me building VIP makes sense when one is "inventing the wheel" in the race with the rest of the industry, i.e. when vendor solution are not mature yet..."

Even here, what if a vendor collaborates with you to do this i.e. while you are developing an IP, another vendor collaborates with you for developing a VIP. You get a chance to customize the VIP to your needs or prioritize the features based on your requirements and yes, at a lower cost & no added cost (of development). The vendor would be able to recover the cost by reselling it into the market. You may still differentiate on the IP, the way it is integrated into the system or SW as VIP wouldn't add value to differentiation.