Introducing TrekUVM: Enhancing Transactional UVM Testbenches

In our previous four posts, we have woven a story quite different from the way we’ve talked about Breker and our technology for the past few years. Regular readers know that our focus has been on verifying system-on-chip (SoC) designs by generated multi-threaded, self-verifying C test cases to run on the SoC’s embedded processors. TrekSoC generates these test cases for simulation with RTL or ESL models; TrekSoC-Si generates test cases for emulator, FPGA prototypes, and actual silicon.

The last few posts have pointed out that TrekSoC has had to handle running in a transactional testbench since many test cases send data on or off the chip. We’ve worked hard to ensure that we can integrate easily into testbenches compliant with the Universal Verification Methodology (UVM) standard. Today we leverage this knowledge as we introduce TrekUVM, which generates multi-threaded, self-verifying test cases for a purely transactional UVM testbench.

We’ve worked with customers doing some of the most advanced SoC designs in the world, in such applications as smartphones, tablets, set-top boxes, and automotive “infotainment” systems. But there are many other large, complex chips that do not contain embedded processors and are not classified as SoCs. (Some people call all large chips SoCs but we think that the term “system” implies one or more central processors.)

The most common examples of non-SoC chips are in networking: routers, switches, hubs, bridges, and modems. These may have application processors running fixed code but there’s usually no notion of a programmable central processor controlling the entire chip. Verification of stand-alone processors and graphics processing units (GPUs) also tends to rely on transactional testbenches, in which all control and communication with the design is happening on the chip’s I/O ports.

We’ve talked before about the limitations of trying to stimulate deep behavior in a complex chip purely from the chip inputs, likening it to “pushing on a rope.” For an SoC, it’s easy to see why this is the case. But even in chips without embedded processors, the sequential depth may make it hard to hit desired coverage goals, and thoroughly verify the design, using just a traditional constrained-random UVM testbench.

We’ve been hearing from more and more verification teams who are hitting the wall with the UVM. They’ve liked our story about “beginning with the end in mind” and the way that graph-based scenario models “pull on a rope” to generate test cases that predictably trigger deep behavior and hit coverage targets. Although TrekSoC has the ability to handle their chips, it also contains the C generator, a services library, and other technology of value only to SoC teams.

So that’s where TrekUVM comes in. We’ve stripped out all the SoC-related technology and introduced a product that uses our familiar graph-based scenario models to generate transactional test cases well beyond what a UVM testbench can do with constrained-random stimulus alone. TrekUVM connects simply to all existing UVM verification components (UVCs) and can be adapted with little effort to support other testbench methodologies (OVM, VMM, custom, etc.)

TrekUVM generates a runtime testbench element called “TrekBox” that coordinates all aspects of the running test case and gathers coverage. Note that the test cases may be multi-threaded if the chip supports multiple transactions running in parallel. No virtual sequencer or scoreboard is needed; the test cases handle stimulus, results checking, and system coverage. Here is a representative example of a non-SoC design running in a transactional UVM testbench with TrekUVM:

We’ve been working with leading customers for some time to define the specific features to make TrekUVM essential for them. We’re very excited at the response and hope that we’ve managed to pique your interest today. We’ll cover more details of the product in upcoming blog posts. In the meantime, we have more information on our Web site and a white paper that you can request. Enjoy our latest addition to the Trek family.

Tom A.

Tags: Breker, coverage, EDA, functional verification, graph, portable stimulus, reuse, scenario model, scoreboard, sequencer, SoC verification, transactional, TrekSoC, TrekSoC-Si, TrekUVM, UVC, uvm

This entry was posted on Thursday, August 14th, 2014 at 3:46 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.