Would You Rather Push on a Rope or Pull It?

Last week we talked once again about our familiar mantra to “begin with the end in mind” when performing SoC verification. We described the enormous value that graph-based scenario models provide by enabling automatic test case generation from desired results. TrekSoC can walk the graph backwards, from result to inputs, and generate the C code necessary to exercise true user-level test cases across multiple threads and multiple heterogenous processors.

It’s clear even to the biggest fans of the Universal Verification Methodology (UVM) that this standard breaks down at the full-chip level for an SoC containing one or more embedded processors. The UVM, for all its good points, does not encompass code executing on processors and does not provide any guidance on how to link such code with the testbench that connects the chip’s inputs and outputs. The value of scenario models for SoCs is clear. But what about large chips without embedded processors? Does Breker have a role to play there as well?

In fact, we do. The short answer is that we can operate perfectly well in a testbench-only environment. We’ve discussed before how TrekSoC enables vertical reuse, with the same graphs usable from individual IP blocks through subsystems through full SoC simulation. In particular, we can operate in the common UVM testbench environment in which the processor models are replaced with bus UVM verification components (VCs). In this case, we do not generate C code, but rather transactions that connect all the chip’s I/O ports.

So it is clear that we can run in a purely transactional mode for blocks or SoCs with the processors removed. As you might expect, our graph-based scenario models and automatic test case generation also work very well with large chips that most people do not call SoCs because they do not contain embedded processors. The networking industry develops many large switches and routers that do not have a central CPU controlling the I/O blocks. For such chips, verification remains a purely transactional challenge.

The question then is whether the UVM suffices for these chips and, if not,  what role Breker can play. In the last six months or so, we have started hearing from more and more non-SoC teams that they are having difficulty full verifying their large chips with the UVM alone. They are finding it hard to stimulate targeted deep behavior purely by applying constrained-random stimulus on the inputs. We use the term “pushing on a rope” for this dilemma because it’s hard to steer stimulus from the inputs alone.

Solving this problem is one of the main reasons that Breker decided to focus on the use of graphs for functional verification. Because graphs begin with the end in mind and trace from outcome to inputs, the test case generation process is like pulling on a rope rather than pushing on one. The bottom line is that graph-based scenario models are more effective than UVM constrained-random stimulus at hitting certain deep corner cases. Before TrekSoC, this was the precise focus of our original product Trek.

Note that we not proposing to replace the UVM. We leverage the UVM verification components (VCs)  in the testbench and connect directly to them to generate transactions and check results. We believe that our test case generation is most useful as a supplement to traditional UVM testbenches. We can fill in the deep behaviors and coverage holes that are hard to reach while providing our unique system-level scenario coverage as a complement to traditional functional and code coverage metrics.

We have just published a new white paper that shows an example of a sequentially deep networking chip, discusses the challenges of using the UVM alone to verify it, and describes how graph-based scenario models can help. To request a copy of “Why Graph-Based Verification? Don’t Push on a Rope!” please visit our case study and white paper page and check the appropriate box. We’ll send it right away and we welcome your comments. Thanks for your interest!

Tom A.

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

Tags: Accellera, assertions, Breker, coverage, EDA, formal, functional verification, graph, portable stimulus, pwg, reuse, scenario model, SoC verification, standards, test generation, working group

This entry was posted on Tuesday, July 8th, 2014 at 5:11 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.