Monday, February 13, 2012

Verification IP : Changing landscape - Part 1

For decades, EDA industry has been working out options to improve their offerings and ensure silicon success for the semiconductor industry. A few decades back, while the EDA giants were unknown, design automation was exercised individually in every organization developing a product. Gradually these tools moved out of the design houses and the ‘make vs buy’ decision carved a new league with EDA front runners. Talking specifically about verification, while the simulation tools were procured from outside, the in house CAD groups were still required to develop a flow for automation, self checking, regression management and data analysis. In the last decade, all of this came up as a package from EDA vendors thereby further squeezing the CAD teams in the design houses. So, what next?  Well, the recent acquisitions in this space i.e. Cadence acquiring Denali, Synopsys acquiring nSys and ExpertIO indicate where we are heading. Initially the VIP providers were able to sustain with licensing and basic verification support model but now the pressure is surmounting as VIPs get commoditized. The VIP only vendors will have to identify themselves either with the EDA vendors or with Design service providers wherein the VIPs complement other offerings. Before moving ahead let’s discuss what is a VIP?
What is a VIP?
A Verification IP is a standalone ‘plug and play’ verification component that enables the verification engineer in verifying the relevant DUT (design under test) module at block, sub system and SoC level. Based on the need, the VIP can act as a BFM to drive DUT signals or MONITOR the signals and VALIDATE them for correctness and data integrity. It may have a set of protocol CHECKERS and test scenarios to confirm compliance with the standards (if any) or COVER groups identifying corner cases and test completeness. VIPs are developed using HDLs or HVLs with standard methodology or as a set of assertions. It needs to have enough APIs providing flexibility for modifying the internal units as per DUT. User should be able to extend the available monitors, scoreboard and checker hooks while developing a verification environment around this VIP. Ease of developing scenarios at different levels using available functions and sequences is important in minimizing the verification turn around cycle. Quick integration with other tools like coverage, simulate, debug and transaction analysis is critical in successfully deploying the VIP.  Finally the most crucial is the support provided by the VIP vendor to the user in responding to issues and upgrading the VIP as the standards evolve.
The common VIPs available include –
- MIPI protocols like DSI, CSI, HSI, SlimBus, Unipro, DigRF & RFFE.
- Bus protocols like AXI, AHB, APB, OCP & AMBA4.
- Interfaces like PCIexpress, USB2.0, USB3.0, Interlaken, RapidIO, JTAG, CAN, I2C, I2S, UART & SPI.
- Memory models & protocol checkers for SD/SDIO, SATA, SAS, ATAPI, DDR2/DDR3, LPDDR etc.

Companies providing the above VIPs fall into one of the below categories -
- EDA vendors
- VIP only providers (some of them offering IPs also)
- Design services companies

Although, there is a lot of IP development still continuing with the design houses, the motivation to procure VIP from outside is much higher for obvious reasons. 

In the next post we will discuss the challenges for new entrants that raise barriers to entry and role of Soc Integrators, EDA companies and design services organizations in this changing landscape.

Related posts -
Verification IP : Changing landscape - Part 2
Choosing the right VIP


  1. LinkedIn Groups : Design Verification Professionals

    Other challeges today ,VIP vendor faces is multiple available methodoogy, Say for example VIP developed in VMM is friendly towards synopsys simulator unlike cadence simulator.Considering this bottle neck, EDA vendors and trying to merge methodology say UVM is catching up ,so that methodolgy doesn't have bottle neck in using a VIP.SOC verification environment needs VIP supplied from different vendors and different Methodology. Reference model developed in one language needs to be connected to TB in different language, Sequence written in one language needs to be connected to TB in different language. Todays world is catching up with OVM_ML methodology for component in multiple language .

    Posted by Kesava viswanathan Sivanthi

  2. Gaurav,
    It is my understanding that there is no common 'library' of I/F's that folks can use so that they can make their individual IP blocks conform to these I/F's and consequently have massively beneficial effects to ESL TLM efforts and chip Verification models. If your second article could address this, it would be extremely helpful.

    1. Dear Reader,

      I agree that there is no common library of I/Fs but then the VIP vendors do provide common VIP license such that you can access any of the VIPs available in that portfolio. These VIPs do have Compliance Test Suite i.e. Checkers and Test scenarios that validate the protocol specific checks for that interface. With the help of these you should be able to confirm that the block interface complies with the standard interface.
      If you are referring to a specific interface please let me know ( and we can discuss further.

      Thanks & Regards,
      Gaurav Jalan