Verification Reuse from Transactional Testbenches to Embedded C Code

In our previous two posts, we went into considerable detail on the vertical reuse of verification information from IP block to subsystem to system. We have focused on how graph-based scenario models enable simple composition as you move up the design hierarchy. This type of reuse is not possible with traditional testbench elements such as UVM scoreboards and virtual sequencers. Once again, this is not a slam against the UVM, but rather a basic trait of constrained-random testbenches.

We skimmed over one aspect of vertical reuse: the transition from a “headless” SoC subsystem with no CPU to  full-chip simulation with our automatically generated multi-threaded C test cases running on the SoC”s embedded processors. We also skipped the question of whether or not our graph-based scenario models can generate full-chip tests for chips that do not contain processors and are not classified as SoCs. This post links these ideas together and answers the question. Let’s start with a reminder of how vertical reuse works with TrekSoC:

The top left is easy to understand: TrekSoC is generating C test cases to run on the SoC’s embedded processors. This is the most differentiated aspect of our verification solution and the “leading story” in most of our technical material. However, some customers are unable to achieve sufficiently fast processor simulations even with the optimized test cases we generate. These customers may choose the middle option, running the processor or processors in headless mode.

In this case, each processor is replaced by  UVM verification component (UVC) that executes the processor bus protocol. The processor bus effectively becomes another I/O port to the chip, with the UVC operating much like like a UVC for the camera, display, and SD card ports in this example. There is a subtle difference: the bus cycles generated need to resemble those that would be generated by the actual processors running code.

The whole point of generating C test cases for an SoC is that the processors are in charge. They must configure the IP blocks and set up the use cases that tie multiple IP blocks together. When the processors are removed, the bus UVC has to perform this task. This is possible because the same scenario model that drives the C generation also drives the transactional connections to the UVCs in testbench. All stimulus, results checking, and system coverage derives from the scenario model.

So we know that TrekSoC is smart enough to handle processor code, headless processor bus interfaces, and peripheral  interfaces such as SD card, USB, or PCI Express. We’ve skipped over the question of whether we can verify a design that has no notion of a central processor that we can program. There are many examples of such designs, especially in networking and telecommunications. While some types of modems, switches, and routers have processors, many do not. Can TrekSoC verify these non-SoC designs?

The answer is a resounding “yes!” After all, TrekSoC already has to understand how to talk to non-processor peripheral interface UVCs in the UVM testbench. If the design has only those interfaces, there is no requirement that a processor or processor bus must be involved. In our next blog post, we’ll talk more about how we accomplish this. In the meantime, we’d love to find a good term for large, complex chips that do not contain processors and are not SoCs. We have yet to discover  a name we like. Please put your thinking cap on!

Tom A.

Tags: Accellera, Breker, coverage, EDA, functional verification, graph, portable stimulus, pwg, reuse, scenario model, scoreboard, sequencer, SoC verification, standards, UVC, uvm, working group

This entry was posted on Wednesday, July 30th, 2014 at 5:53 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.