Will Graph-Based Scenario Models Dominate Verification?

In last week’s post, I responded to an article in which Jasper‘s CEO is quoted as saying “formal will dominate verification” and that concluded “at some point in the future, formal will be the default choice for every verification task in the way that simulation/emulation is today.” I challenged this statement, giving examples of SoC verification where I do not believe that formal analysis alone can provide the answer.

Thinking about formal in that way naturally led me to ask the same question about Breker’s technology. Will graph-based scenario models “dominate verification?” At some point in the future, will graph-based scenario models “be the default choice for every verification task in the way that simulation/emulation is today?” As I promised last week, I’ll offer my thoughts on these questions as well.

The first and most important point to make is that we are not looking to replace simulation or emulation, so the second question above doesn’t really make sense. Graph-based scenario models actually make simulation and emulation more efficient, both in the time to generate test cases and in the power of each test case run, while finding more bugs more quickly.

TrekSoC generates test cases for any platform with a testbench: ESL modeling, RTL simulation, or hardware-accelerated simulation. TrekSoC-Si generates test cases for hardware platforms where there is no longer any notion of a testbench: in-circuit emulation (ICE), FPGA prototyping, and actual SoC silicon. The same graph-based scenario models are used by both products, providing an industry-leading level of horizontal reuse across a project.

Let’s set aside the hardware platforms, since TrekSoC-Si provides the only viable alternative to trying to boot up the operating system on the first day. In case of simulation, scenario models do face an alternative: UVM testbenches. Perhaps the most interesting question is whether graph-based scenario models will “be the default choice for every simulation task in the way that a testbench is today?”

Central to Breker’s success is the fact that most SoC projects don’t have effective testbenches at the full-chip level. Once embedded processors are included in simulation, UVM does not provide an answer for how to coordinate testbench activity with code running on the processors. TrekSoC provides an excellent solution since the test cases running on the processors communicate with the SoC I/O ports via the TrekBox module. The only part of the testbench that TrekSoC requires is some sort of bus functional model (BFM) on each I/O port. If UVM verification components (VCs) exist, TrekBox can connect directly and easily to them.

The user can also choose to keep any passive components of the testbench included in the simulations with TrekBox. Protocol monitors, assertions, scoreboards, functional coverage, and even code coverage all run perfectly fine in simulation of TrekSoc-generated test cases. So clearly we can leverage an existing testbench, but is one really needed at all?

Today, users typically have UVM chip-level testbenches but they run only minimal connectivity and sanity checks. Over time, as graph-based scenario models become the primary method for full-SoC verification, I believe that some users will abandon chip-level testbenches entirely. The BFMs or VCs will be reused from IP-level verification, as will some of the passive components.

Graph-based scenario models are also ideal for vertical reuse, from IP to subsystem to SoC level. This leads to my final question: will scenario models also replace UVM testbenches for IP blocks? The potential is certainly there. Since TrekBox connects to the chip’s I/O ports, TrekSoC can generate purely transactional test cases for blocks without embedded processors.

I expect that different methods will be used for different IP blocks. We’ve already seen that some types of blocks amenable to formal analysis are 100% verified with no simulation until higher levels. In some cases, especially for standards-based IP, a sufficient UVM testbench will already exist and there may be no compelling reason to add graphs to the mix.

However, many IP blocks will be verified using TrekSoC, some leveraging an existing testbench and some with no testbench in the mix. We’ve already seen some of our customers embrace vertical reuse, verifying most of their blocks with scenario models and reusing the graphs by instantiating them in the full-SoC scenario model.

As I noted in my last post, there are aspects of verification that formal handles very well, including I/O port connectivity, clock-domain crossings, and power-domain control. It is also essential to run production code on the hardware design to perform hardware-software co-verification. Graph-based scenario models are not the choice for “every verification task” despite their high value.

However, they do cover a much wider swath of the total verification effort than formal analysis, or testbenches for that matter. Graph-based scenario models scale vertically from IP to full SoC and horizontally from simulation through all forms of hardware platforms. If you’re not using them now, you’re missing out on the next big wave in verification.

Tom A.

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

Tags: Breker, constrained-random, emulation, formal analysis, functional verification, graph, integration verification, IP, scenario model, SoC verification, TrekSoC, TrekSoC-Si, verification IP

This entry was posted on Tuesday, November 19th, 2013 at 12:40 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.