Will Breker Become an IP Company?

In last week’s blog post, we talked about the emergence of the commercial IP industry and shared some personal experiences. Although Breker is an EDA company and not known for IP products, we intersect with semiconductor IP (SIP) and verification IP (VIP) in important ways as we work with our customers. We’re also starting to offer our own scenario model IP (SMIP) as part of accelerating and improving verification even more. We’d like to expand on these topics in today’s post.

We have few if any customers or prospective customers who don’t use commercial VIP in their testbenches. After all, if you’re designing a standard interface you want the best verification possible that you’re meeting the standard. A VIP model that’s been used by dozens or hundreds of other projects serves as a pre-silicon “plugfest” where you get to verify your implementation of the standard against what others have done. Now that the Universal Verification Methodology (UVM) is nearly ubiquitous, most VIP is developed in a fairly consistent manner.

This makes our job of integrating into customer testbenches much easier. If TrekUVM is generating test cases for a transactional UVM testbench, you simply connect our TrekBox run-time module to the transactional interfaces of the VIP components. In UVM-speak, we take over the sequencer functionality from the testbench. This means that we can leverage all the existing UVM-compliant VIP on the interfaces. It also means that neither we nor you have to develop scenario models that communicate at the bit-level details of the standard. We hook on to the “back side” of the VIP components and let them do the conversion work to and from the interface.

When TrekSoC generates C test cases for an SoC’s embedded processors and transactions for the UVM testbench in which the SoC is simulating, we talk to the VIP components on the interfaces in the same way as for a transactional testbench. When a test case requires data to be sent into the chip, TrekBox directs the appropriate VIP to supply that data. When data must be read off the chip, the VIP gathers the data and sends it to TrekBox for comparison with expected values. This is how we make all test cases self-checking, whether driven by the testbench or by code in the embedded processors.

We have access to the VIP libraries of multiple EDA and IP vendors, so we can proactively ensure that mutual customers will not have problems. One interesting thing we’ve observed is that many VIP vendors do not ship enough tests to completely cover the standard protocol, even as measured by their own coverage models. We’re not quite sure why this is the case, but it gives us the opportunity to add value by automatically generating a richer set of test cases that exercise corner cases and optional features in the protocol.

We also have few if any customers or prospective customers who don’t use commercial SIP in their designs. Quite often we are helping to verify a chip that contains SIP from multiple sources. We also have access to the SIP libraries of some EDA and IP vendors, so again we can proactively verify that we work well with them. Note that our mutual customers usually do not want us to verify the full functionality of commercial SIP, but rather to exercise the SIP in the context of system-level verification.

This will change as we work directly with IP vendors to verify their SIP products with our Trek family products. When we work with an IP vendor to verify their standalone SIP, we create a graph-based scenario model for the SIP. Since a graph is the most reusable form of VIP, it can be easily instantiated into a chip-level scenario model of any team using the SIP. Over time, we expect to partner with multiple IP vendors to produce pre-built SMIP titles that we can offer as products to mutual customers.

Finally, we are working on additional SMIP-based applications (apps) pre-configured to solve specific verification problems. Our first such offering, the Coherency TrekApp, is now available to help verify multiprocessor cache coherency. It has already proven very popular. Breker is not an IP company, but we will expand our SMIP offerings and continue to work closely with SIP and VIP. We’d like to close with a joke: What do you call partially complete graph-based scenario IP products? PARSMIPS, of course!

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Breker, cache coherency, EDA, functional verification, graph, IP, reuse, scenario model, semiconductor IP, SIP, SMIP, SoC verification, TrekApp, TrekSoC, TrekUVM, verification IP, VIP

This entry was posted on Tuesday, November 18th, 2014 at 3:00 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.