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