More on the UVM: Processor or Verification Component?

Our last post on the relationship between the Universal Verification Methodology (UVM) and Breker’s technology was very popular. In only a week, it has become the fifth-most-read post in the nine-month history of The Breker Trekker blog. Clearly people are interested in the UVM and what strengths and weaknesses it brings to the ever more complex world of SoC verification.

This week we’d like to continue the discussion with a topic that we did not address last week: how the UVM offers an alternative to running embedded code by replacing one or more of the processors in the SoC with a verification component (VC). Our CEO, Adnan Hamid, addressed this topic in an Electronic Design article last November.  We’d like to revisit some of the key points of that article in the context of last week’s UVM discussion

For verification teams using the UVM on their SoC designs, the most common approach to embedded processors is simply to remove them from simulation. The processor bus then becomes a virtual I/O port of the chip and, like the other ports, can use a UVM verification component (UVC)  to communicate with the testbench. The UVC can be thought of as a transformer, taking in transactions from the testbench and converting them to the signal-level protocol (USB, PCIe, etc.) required by the particular I/O port.

A processor bus, for example ARM’s AMBA family, is just another protocol as far as UVM is concerned. A UVC can connect to each stub remaining when a processor is removed and communicate with the testbench and the other UVCs via the virtual sequencer. A simple example of the resulting SoC testbench is as follows:

There is one clear advantage of this approach: no software is needed to run on the embedded processors. Traditional verification teams are usually not embedded programmers and in any event hand-written tests are difficult and time-consuming to write. Production software is usually not ready during the verification phase of an SoC, and in any event is likely to run so slowly in simulation that it is impractical. Handing the task of stimulating the processor bus off to the testbench seems to make sense.

However, the processor UVC method runs into two serious limitations. First, it is not portable across the life of the project. As soon as the SoC design moves into in-circuit emulation or FPGA prototyping, the UVCs and the rest of the testbench no longer exist. At that point the only solution is running code on the embedded processors.

Even in simulation, it is hard for a testbench to recreate the sort of complex activity that actually occurs in an SoC. Multiple processors, or even multiple threads on a single processor, interact in ways that cannot be duplicated in a testbench. The following is a screen shot of a run-time test map showing Breker’s automatically generated test cases executing with two threads on each of 12 processors in a real user SoC:

There is simply no way that even the most experienced verification engineer can juggle twelve processor UVCs and the virtual sequencer to produce this level of test case, with multiple user scenarios hopping from thread to thread and processor to processor. This clearly shows the advantage of leaving the processors in the simulation model. Of course, there is also no way that even the most experienced embedded programmer can hand-write such a test case. Automation is a requirement.

Breker’s test cases run on bare metal and are designed to be efficient, so they will execute in simulation even when production code would be unacceptably slow. Any overhead incurred to keep the processors in the design is more than offset by faster and more thorough verification. Finally, the test cases are available early in the development process and can run on every platform: virtual prototypes, simulation, acceleration, emulation, FPGA prototypes, and even actual silicon in the lab. Please give them a try!

Tom A.

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

The test map shown in this post is from our new x86 server validation case study. Please request it at www.brekersystems.com/case-study-request/

Tags: Breker, EDA, emulation, functional verification, reuse, scenario model, simulation, SoC verification, system coverage, test generation, TrekSoC, TrekSoC-Si, UVC, uvm, verification component, verification IP, VIP

This entry was posted on Tuesday, February 4th, 2014 at 5:08 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.