Cooking at Home or Eating Out? - The Pros and Cons of Homegrown VIP

By now, we're all pretty much convinced that reuse is essential in the semiconductor industry. Gone are the days when we built everything from scratch an re-invented the wheel on each project. Today, to build a new SoC we stitch together multiple blocks that we've already used on previous projects, maybe tweaking them a little, while only designing those new things that will help our product differentiate itself from the competition.


This is a companion discussion topic for the original entry at https://verificationgentleman.netlify.app/2015/04/12/pros-and-cons-of-homegrown-vip.html

Hi Tudor,

Nice post. While consulting with various companies I have come to a conclusion that the decision is also dependent on the DNA - the culture of the company. On other aspects I did write something on this subject too -

Best Wishes
Gaurav Jalan

For sure a lot of teams/companies have a dislike for all things NIH (not invented here).

Why limit yourself to one or the other? Why not the best of both world using both home grown and 3rd party VIP. Nope, I am not talking about pick the right VIP based on ROI on different interfaces. In fact we have both 3rd party and home grown VIP (same protocol) in the same testbench hooking up to the same interface. Depending on the test requirement, we can choose the most cost effective VIP for the job.

For example, if I need to test AXI compliance of the block, the testbench will instantiate the 3rd party VIP to stress test the bus. For most of the testcases that uses AXI as a dumb register bus, we will use the light weight home grown AXI VIP to save license cost.

Implementing our light weigh AXI VIP is easy and cheap as long as we limit the supported features and let the 3rd VIP do the heavy lifting. Moreover we can use the 3rd party VIP to QA our homegrown VIP.

There is also a very important intangible benefit of building light weight homegrown VIP. The task is a provides very good hands on training in verification methodology and in-depth ramp up of the protocol domain knowledge to the less experienced verification engineers.

That’s a really interesting take on it, have your cake and eat it too. If you’re starting your homegrown lightweight VIP from a solid base and adding to them, they could even have the potential to replace the 3rd party solutions completely in the long term.

@hevangel: Beside your example I would also consider: low complexity protocols(e.g. APB) or VIPs that support a protocol’s upper layers that can stack on top of 3rd party VIPs (e.g. for example a light TCP/IP VIP stacked above a 3rd party Ethernet VIP). The second one is especially efficient when there is no need for full coverage of the protocol stack given that a silicon-proven rtl IP is used.
In case you are not interested in data collection you can develope an SVA package instead of a VIP.
As a side note: might be easy to develop a VIP, but than you have to qualify the VIP. This kind of effort I could see many times being ignored or minimized by the VIP developers and project managers alike.

@tudor:
On protocol exceptions:
I think it’s a good option to use branches or overwriting classes in the local environment instead of forcing exceptions into the VIP.

On VIP ownership:
There should always be ONE engineer assigned to be the owner of one or more VIPs, which means it is the one to decide what should be updated, added or removed. The VIP owner handles the release process and mediates change requests.

On proprietary VIPs:
If the protocols are part of the company’s IP and sensitive to outsourcing, most probably the company will go for a homebrew solution, which does not exclude consultants doing it.
Also a home brew VIP is not free of risks: the more complex the protocol the higher the risks of not being standard/protocol aligned, schedule slips, simulator portability issues.

On replacing a 3rd party IP by an internal VIP:
Companies have to balance between internal sourcing and 3rd party IP procurement or VIP development outsourcing. VIP development,qualification&maintenance is not part of the core business of an ASIC/SoC company and in the long run can be dead weight.

Nowadays many of the ASIC/SoC companies are integrating IPs and not designing those from scratch. These companies MUST focus their QA efforts on the integration verification and not IP verification. Given that, the company will not care too much of the small details of the protocols supported by the IPs and then they can use a lightweight VIP or rent a VIP for a limited amount of time.

I am confident that for complex protocols (e.g. USB, DDR, AHB, Ethernet) it’s more efficient (e.g. considering time-to-market, risk reduction, inventory) to rent VIPs, rather than developing those from scratch. It’s a heavy project to develop, qualify and maintain a DDR4 VIP. Leaving aside development, which is more or less similar to software development, you have to seriously consider qualification and maintenance effort. “Silicon-proven” label is a quality standard, either we like it or not, and that is why qualification might require silicon proven references, which means you will have to “rent” a silicon proven IP. One should consider that dependencies updates (e.g simulator, UVM, SystemVerilog Standard) trigger qualification sessions for every update increasing the maintenance effort.

I think the “internal vs 3rd-party” decision should seriously consider the time-to-market, qualification&maintenance effort, associated risks, next technology update, dependency associated risks, not just how much it takes to develop it.

On AMIQ VIPs:
Those were released for the open public to use. there will probably be updates, but without any commitment.

@Stefan I agree that someone should be put in charge of a piece of VIP and analyze any potential changes to it prior to implementing them. What you have to be careful of is the case where the owner is also a user of the VIP and adds stuff to it that is only relevant for their project instead of implementing such functionality inside their verification environment. That’s why we moved to OOP, to be able to separate the generic from the specific.

W.r.t. buy vs. build, this post wasn’t written in the spirit of convincing people to build their own VIPs. I just wanted to warn anyone that already made this decision in favor of ‘build’ what to look out for, based on my experience.