Choosing the right VIP

In past few months, while interacting with customers, I came across a couple of cases where the VIP played a spoilsport. In one case, the IP & VIP were procured from the same vendor during the early phase of standard protocol evolution. One of the key USPs of the product was this IP and the demonstration of the complete reference design was anticipated at a global computing event. The limitations of the VIP were revealed quite late during SoC verification. The team struggled hard to manage the bug rate in the IP itself during the SoC verification phase. Finally the product got delayed to an extent where the company (~startup) couldn’t manage to sustain and went for an asset sale. The problem wasn’t selecting the IP & VIP from the same vendor but lack of home work and maybe a wrong business decision during the selection process.

In another case, an in house developed IP having seen multiple tapeouts was getting validated on a new SoC architecture targeting a different application. The VIP was third party which had been used to verify the IP throughout. After integration testing at SoC level, while developing usecase scenarios, the limitation of the VIP came forward. Since the schedule didn’t allow the liberty to add features to the VIP and validate this scenario, the team went ahead with the tapeout. Unfortunately the application didn’t work on silicon and the root cause analysis revealed a bug in the IP itself. Result, re spin required.

Showstopper bugs, Project cancellations, Tapeout delays etc. all point to missing the market window and the post mortem may point figure to the VIP!!!

Selecting the right VIP demands a detailed evaluation process along with a comprehensive checklist to compare the solution from different vendors. To find available solutions in the market, www.chipestimate.com and www.design-reuse.com are quite useful. After identifying the set of applicable vendors, it is important to  collect relevant information for initial analysis –

- Detail documentation i.e. reference manual (architecture of VIP) and user manual (how to use it). These documents should list out all aspects of the VIP functionality including parameterizable sequences, component configurations, APIs, parameters, coverage, error messages etc.

- Understanding the process of VIP development from vendor i.e. how is the VIP validated, the maturity process, how many and what kind of design it has verified. The release process, bug reporting mechanism, turn around time for fixing bugs, commitment and plans to support the evolving standards.

- Vendor overall VIP portfolio, languages & methodology used, membership & participation to the relevant standards, development/support staff availability and domain expertise, level of onsite support possible.

- Standard compliance, compliance coverage report, items not supported in the current release, list of assertions, code & functional coverage report.

- Support across methodologies, simulators, accelerators, formal verification engines and ESL verification.

- Exiting customer references.

A detailed comparative study of the above data will help in narrowing down the search to final 1 or 2 vendors. The next phase involves qualitative analysis to validate the data provided by the vendor and the assumptions made during first phase by the evaluator. Here the engineer(s) needs to play around with the VIP using the examples provided by the vendor / test in target env / create a short circuit env with master-slave agents of VIP and try different scenarios to evaluate –

- Ease of use in terms of configuring the components, using the sequences, portability from block to system level, how would it work when simulated in parallel with other VIPs in the SoC verification environment.

- Does it meet the requirements of the metrics planned for determining verification completion and to what extent does the VIP inherently reports it by itself.

- APIs provided to develop tests for customized functionality of the IP, developing real life scenarios, directed tests, stress testing, errors injection & detection capability, debug and observability.

Interestingly the experience with the vendor during the evaluation phase indicates the level of support that can be expected further. The key to this two phase evaluation process is the checklist. VSIA provides a comprehensive QIP metrics (Final VSI edition) that provides a jump start to this evaluation process.

As it is said - "the devil is in the details", an additional effort during the start without overlooking the finer points can prevent from serious problems later. 

It would be interesting to learn your VIP evaluation experience. Drop a comment now!

Related posts -
Verification IP : Changing landscape - Part 1
Verification IP : Changing landscape - Part 2