VIP: Behind The Velvet Rope

By Ann Steffora Mutschler
Some years ago, as engineering teams began to incorporate more protocols into designs and as those protocols grew in sophistication and complexity in order to deliver additional performance, the verification task grew concurrently. At the same time, the design IP market was growing as complexity drove re-use of components, along with verification components—most commonly referred to as Verification IP (VIP).

As the verification task grew in scope, breadth and depth, verification engineers were challenged to develop a level of protocol expertise to write effective testbenches, said Neill Mullinger, Synopsys’ VIP product manager.

But it’s still fairly common for a project to get design IP with nothing around it, noted Andy Meyer, verification architect at Mentor Graphics. “If you look at the effort that goes into developing the verification IP, and if you also think about an SoC development and the amount of work that goes into developing the monitors and the drivers and the protocols and all this stuff, it remains a larger effort than the design IP itself.”

In fact, Meyer said one of the big pushes is to have an entire team, when they take a block that’s going to get used in an SoC or in multiple SoCs, develop the design, the protocols in the verification IP and all the other verification stuff—and package it all as one.

“These protocols are miserably complex, so verification IP developers have to suffer through understanding every last detail of it. The other thing they can do, particularly if they understand multiple abstraction levels, is give an ability to look at what’s happening in a protocol without having to understand it at the level that the IP developer or the verification IP developer have to understand it. That is, it gives you the transactions, it gives you a more abstracted view. You connect these two blocks together they’ve got to talk and it will not only check the thread but abstract out the information that you need as an SoC developer without needing to understand all that down below,” Meyer explained.

Source: Mentor Graphics

So what exactly is verification IP and where does it fit into all of this?

“It really is a type of content that allows for effective verification and integration of SoCs and systems, providing a meaningful way for various elements that go into a chip or that go into a device with multiple chips to come together and communicate effectively versus people having ‘aha’ moments where they are already late on the time-to-market window,” said Michal Siwinski, senior director of solution and product marketing at Cadence. “It sounds straightforward, but it’s actually something that interestingly enough has only been coming into its own in the last few years.”

Technically speaking, verification IP is not even considered IP, according to Sam Stewart, an eSilicon architect. It fits more specifically under EDA tools, which can be generally classified into assertions, high-level languages, and suites.

He pointed out that the problem with HDL assertions is really the concept itself, which is that assertions are to be incorporated into the source HDL RTL at the time that the source RTL is written. “The reality is that the assertions are not included in the original Verilog RTL because the engineer is inevitably trying to capture the design, and this job is difficult enough. It’s not really possible for a good engineer to both capture the design with the RTL and also do the assertions, as he is juggling 1,001 logical concepts in his mind in order to just capture the design. And, there is just no time for assertions in the original creation due to the time constraint. But it is still true that the main difficulty in including assertions is the difficulty of re-directing one’s attention away from the complex task of creating the RTL to the task of creating assertions.”

Once the RTL is generated, the design is simulated for basic functional operation. After this simulation is in place, then the question is: Does it make sense to go back and add assertions to the RTL? Or, wouldn’t it be easier to just enhance the simulation testbenches to cover the various conditions? The answer to the first question is that HDL assertions can be lengthy and complicated, and thus hard to create. It’s probably fair to say that these assertions are “close” to being as difficult to create as the original RTL. And, finally, Stewart pointed out, “HDL assertions are themselves subject to bugs. So an EDA tool that could go back and add assertions to the original RTL would be valuable. Or better yet, develop a tool that could create a companion file for the assertions without modifying the source HDL RTL. This level of sophistication does not yet exist in the EDA world today. The methods targeted today are tools that attempt to do so anyway by a combination of RTL analysis plus querying the user with a long list of questions to remove the ambiguities.”

VIP’s role in system-level design
Verification IP has a key role in verification and is a big part of the effort. As very complex systems are being pieced together, more and more design IP is being re-used, said Jason Polychronopoulos, product marketing manager for Questa VIP at Mentor Graphics.

“At the same time,” he said, “that necessitates more and more re-use on the verification side, so companies are internally re-using verification as often as possible and verification IP forms a big part of that. The initiative to have a standard verification methodology is part of that too.”

In terms of fitting into a system-level approach, VIP fits into virtual prototyping technology as another model and is a component that helps to allow for early testbench development, which is particularly important as engineering teams increasingly look toward software-driven verification to complement traditional hardware-driven verification.

Marc Serughetti, director of product marketing in the systems group at Synopsys, noted that in this case the verification team wants to develop software-based tests that complement traditional testbenches. The virtual prototype that is available early for software development and debug purposes can be re-used to develop software tests sooner, before the DUT RTL is available.

“Like their software development colleagues, the verification team can develop software on the virtual prototype earlier—in this case the software are tests for software-driven verification. Once the DUT is available, the DUT replaces the virtual prototype and software driven tests can be run on the new RTL hardware,” he said.

A second way virtual prototypes provide value is by enabling hardware/software co-verification. “In this case, the virtual prototype acts as the system-level testbench for new subsystem hardware and software. Initially the virtual prototype is modeled at the transaction-level for driver development and the hardware-software interfaces are debugged at the system level. The verification team can replaces the TLM components of the new subsystem with the new subsystem RTL. Using RTL co-simulation, the virtual prototype runs the software necessary to co-verify the new RTL subsystem using the drivers and other system software. Again, this is complementary to other forms of verification, providing the system-level view,” Serughetti added.

Source: Synopsys

Moving forward, it is clear, out of the $50 million to $100 million it takes to develop an SoC today (depending on whom you ask), verification makes up as much as 40% of that cost. As a result, it becomes obvious why there is so much focus on re-use of verification IP and re-use in general. “You’re doing it so that your design is right—so you have the time-to-market benefits and all those other things,” concluded Jack Browne, senior VP of sales and marketing at Sonics.

And it’s getting much, much harder at each new node to get a design right—particularly with market windows perpetually shrinking. That’s making VIP far more popular than ever before—with interest likely to grow even further at future nodes and in stacked configurations.