It appears that Cadence and Mentor are to deliver on the promise of SystemVerilog by combining their efforts into a single unified platform - brilliant!

I say “platform”, because it’s more than just a language, a library or a methodology. It’s also not something that they’re going to hoard to themselves, but a support infrastructure within which third party VIP vendors (like my clients ) can provide value added products and services.

Within OVM, Cadence and Mentor will provide:

• Interoperability mechanisms for Verification IP (VIP) between the two tool sets (Cadence and Mentor)
• Transaction-level and RTL models
• Full integration with other languages commonly used in production flows (such as e maybe?)
• A class library to be available in source code format

Based upon this infrastructure, HDL Design House has already committed to provide Verification IP that are OVM compliant - watch this space!

Why should you care?

To date, there were really three different SystemVerilogs due to different libraries supported by the different simulators. So really nothing changed that much in terms of portability - your choice of simulator dictated the version of SystemVerilog you were to use.

Now, with OVM, the VIP you choose can be portable across two of the three flows: Cadence and Mentor. Implementation details have yet to be released, but it would make sense that the VIP vendor, such as HDL Design House, will test compatibility against an OVM test suite (this will likely be a self-testing mechanism) and be declared compliant and thus portable across Incisive (NCSim) and ModelSim. Great!

This is how the verification engineer really wins:

Use the simulator you’re used to and license the VIP that matches the protocol you’re verifying.

One language, one VIP and multiple simulation and verification environments to choose from!

This is the final installment of a three part blog post in answer to questions Ron Wilson’s posting “Searching for a new SoC abstraction, part 2: verification” posed.

So, if the internal BFM based verification methodology is not removing the development schedule bottleneck and there is a proven commercial solution that saves money, removes the bottleneck without any loss in your end product’s value proposition or differentiation in the market then why isn’t there greater deployment of VIP and it be more recognized as the solution to the problem Ron Wilson raised?

As with the early days of IP in the ’90’s the issues are very similar and the following questions need to be asked of the vendor.

Is the VIP robust?

There are three ways this question can be directly addressed. If the VIP has been used before this is a good indication of robustness, but many of the newer more sophisticated VIPs are yet to be tested due to the newness of the protocol it is to test, this can be a real Catch 22. To break this chain, verify that the VIP has been architected and implemented to conform to the verification methodology guidelines to be used. It also helps that the authors of the guidelines to be used can vouch for the quality of the VIP through their own review. Additionally, most VIP can be licensed for a short amount of time in order to perform an evaluation. Due to the sophistication of the VIP and the environment within which it will be used, this can be done quite thoroughly.

Is the VIP high enough quality?

This concern differs from the previous in that this refers to the “whole product”, i.e. everything that comes with the VIP and not just the VIP itself. Is there adequate documentation? Is it easy to use without touching the code? There have been movements to increase the measurability of this aspect of the VIP through organizations such as VSIA, but I’ll leave that for another post due to recent changes here.

What sort of support is there?

Due to the plug-and-play nature of VIP most issues should be manageable via phone, email or a web based support portal. However, your vendor should be able to provide you with the same level of support you would expect from a vendor of IP of similar complexity. There should also be an option to contract the vendor for training or integration services if necessary. Support should be customized to meet your needs.

What about the business model?

Unlike many “star-IP” cores for license, VIP does not come with a royalty attached to it. A VIP is used per simulator and there is a sliding scale related to the number of licenses used. This is usually a highly negotiable aspect of the process.

Could I have done better myself and will it put me out of a job?

That’s the wrong question to ask and “no” respectively. If the cost-benefit analysis holds it does not matter if it can be done better internally on that one design. The problem is how to scale over multiple projects with significant increases in complexity. Secondly, VIP moves the challenge from developing and maintaining the testbench to performing verification, where the emphasis should be and where the resources are needed. Think of it this way, VIP could save you your job

Picking up from my last post “A BFM is a Simulation Tool, not a Verification Solution”, this post touches on the business weaknesses of an internally developed verification approach and then lists the advantages of licensing Verification IP as the only way to address the productivity issues and ballooning costs of verification in terms of overall SoC development project costs.

As “IP reuse” as a level of abstraction saved the designers from the sea of gates and market pressures, “VIP Reuse” will save the verification engineers from the problems the designers salvation created - thousands of registers and endless states.

If design teams no longer develop their own CPU cores as it’s not where they can differentiate, then why are verification teams spending resources building and maintaining verification environments that do not differentiate the product, do not scale and continue to be in the way of commercial success?

Business Weaknesses of the Internal Solution

Here is a list of the potential business impacts of following the internally developed methodology.

1. A sound business decision cannot be made if there is limited visibility and little predictability in the time it will take for the product to get to market. The existing in-house solution described above is inherently subjective in nature with few metrics to track completeness objectively.

2. Valuable and scarce resources are poorly utilized to build, maintain and even re-build BFMs and verification environments rather than perform actual verification of the designs.

3. Testbenches created are specific to a particular design and usually poorly documented. This results in a sunk cost that cannot be leveraged by other design teams and maybe not even by the same team on a future design.

4. Due to the subjective nature of the creation process of the verification environment, when the design does not perform according to specifications there are now two very large spaces of potential failure instead of one. Is there a problem with the design or is there a problem with the testbench? To hunt for a needle in two haystacks has large direct costs associated with it as both design and verification teams are brought to a halt to address the problem.

The Solution - Verification IP

Companies large and small have invested significantly to create exhaustive portfolios of sophisticated Verification IP (VIP) that can be quickly integrated to create complete system verification testbenches. VIPs not only contain BFMs, but also a sequence driver, monitor and configuration interface. In the same way that SoC design continues to be abstracted up to the “black-box” level through IP reuse, verification can do the same through VIP reuse. The same benefits apply.

Methodology Strengths of VIP

1. Due to their modular nature and the VIP vendor’s business model, VIP are not only deployed across multiple design teams, but across multiple companies. This ensures that the VIP is exercised thoroughly in various flows for chips to be used in widely different applications. This results in a very robust VIP to ensure higher quality of the design in which it is used.

2. All possible scenarios for testing an IP are contained with the VIP and the sequence driver. The sequence driver generates patterns that automatically exercise the BFM across all corner-cases. No tests need to be written.

3. VIP output data that is collected and displayed real-time to provide percentage-complete feedback of what has and has not been exercised relative to the verification plan.

4. VIP are modular in architecture and can be quickly integrated in drag-and-drop environments or using scripts without any direct editing of the VIP itself.

5. Directed tests can be run to exercise specific areas of interest in a design, but random seeds can also be provided to the VIP to ensure all corner cases are exercised, even those unanticipated by the designer.

6. Sophisticated verification environments not only collect and display verification results real-time, but they can also control the simulation itself and to even automatically direct subsequent simulation runs according to results that have been previously gathered.

7. Results are presented in an intuitive graphical format for even the highest-level project manager to easily ascertain the status of the verification process and the quality of the design under verification.

Business Strengths of VIP

1. As progress is presented in real-time and the level of quality of the design that has been tested to date, accurate predictions can be made of when verification will be complete. Therefore business unit managers can make sound business decisions based on data, not gut feel.

2. Verification resources are deployed to carry out verification of a design and are not expended on recreating verification environments.

3. VIP are architected and documented for easy reuse and so any investment made in VIP can quickly be amortized across multiple designs throughout the team or company.

4. As the VIP is to be used across multiple users in different companies the robustness of the VIP increases constantly to remove one of the haystacks within which a problematic needle must be found. In addition, by using this metric driven approach, the search space for the root cause of a problem is significantly reduced if not eliminated enabling root causes of a bug to be rapidly identified and addressed rather than dragging the entire development team to a halt.

5. VIP are usually licensed at a fraction of the cost it would take to build an internal solution.

That should be reason enough to license VIP right there, but what are the down sides. What should you look out for….see my next post: Questions to ask when considering VIP.

Ron Wilson’s DAC posting “Searching for a new SoC abstraction, part 2: verification about the functional verification bottleneck makes very interesting reading, and the comment I started to post started getting way too long to be defined as a “comment”. The post got me thinking about the definition of the problem and a description of the solution in different terms.

As Ron Wilson’s post highlights, the problems of scaling verification methodologies to keep pace with the scaling of the complexity of SoC (System-on-Chip) designs are not being adequately addressed due to time constraints placed on engineering teams caused by said rise in complexity. As I mentioned in my comment, the solution to this problem is extremely similar to the approach that contributed to the rise in complexity in the first place. As design engineers and system integrators are utilizing IP blocks, verification engineers need to increase their productivity equally by utilizing Verification IP - VIP.

The Problem Defined :: A BFM is a Simulation Tool, not a Verification Solution

Verification teams have invested a great deal of time and effort to create verification test benches built upon Bus Functional Models (BFMs) and scripts either developed internally or provided by an IP provider. Reliance upon these internally developed environments result in the following potential resource sinks:

• Re-coding of the BFM as the design changes or a new project begins.

Although some reconfigurability may have been built into the BFM it is difficult to anticipate every implementation of a particular standard, especially for the more complex protocols such as SATA or OCP.

• Waiting for a simulation run to complete before results are generated through the post-processing of data

Many verification environments rely on a post-processing methodology.

• Creation of scenario tables and then the creation of a finite number of directed tests

This resource drain has two impacts. Firstly, the writing and testing of the tests themselves consume a great deal of time. Secondly, risk exposure that all relevant tests have been created.

• Repeated maintenance of scripts as the design changes and/or the environment changes

While engineers endeavor to design in as much automation as possible, due to time constraints they are not able to make a complete solution that can predict future designs and future environments and constraints.

• General low level of reuse of testbenches

Most environments developed internally suffer from poor documentation and a lack of adequate commenting in the code itself. Therefore it is very difficult for another engineer to utilize the environment in a different design or even for the same engineer to maintain and extend the environment in future designs.

• Lack of metric driven methodology to understand coverage

A subjective approach to completeness and the degree to which the design has been exercised is very risky and coming back time and again to extend test patterns to increase coverage that was originally thought unnecessary can cause weeks of delay. Worst of all, this type of delay usually comes very close to RTL freeze when schedule pressure is highest and the largest percentage of development costs has already been spent…i.e. the switching cost for a program is almost at its highest and so the business is locked into the project.

Given these time and resource sinks, the verification engineer expends too much time building and maintaining a verification environment instead of actually performing verification of a design under test. As the complexity of SoC designs has increased reaching into the dozens of cores per chip, the verification engineer is in need of a scalable solution that can be rapidly deployed, configured, utilized and then reused with no rewriting of code and project risk due to a lack of coverage.

The real solution to this problem is Verification IP – VIP - and is to be covered in my next post.