Verification Beginning with the End in Mind

Folks who have been following Breker for a while know that we like the phrase “begin with the end in mind.” It succinctly summarizes why our use of graph-based scenario models is different than traditional constrained-random testbenches.

Suppose that you want to trigger a particular behavior within your design as part of your verification process. With a testbench, you have control over only the design’s inputs, so you might issue a series of input stimulus changes that you believe will cause the desired behavior. You may hit your target, or you may not. Automating your testbench with the constrained-random capabilities of the Universal Verification Methodology (UVM) reduces the manual effort, but there’s still no guarantee that you will trigger your targeted behavior.

As design size grows, it becomes harder to stimulate deep behavior purely from the inputs. With a system-on-chip (SoC) design, a more predictable method is required. That’s where Breker’s TrekSoC comes into play. TrekSoC generates C code to run on the SoC’s embedded processors in addition to input stimulus, so it has much better control of the design. Even more important, this generation is a closed-loop system. When you ask TrekSoC to trigger a particular behavior, you can be 100% certain that the generated test case will hit the target.

We can make this statement precisely because we “begin with the end in mind.” TrekSoC starts with your desired outcome and works backward to determine what the C code has to do and what the inputs have to be in order to trigger the desired behavior. If you don’t specify a particular target, TrekSoc can analyze all possible legal outcomes and produce test cases to exercise them all. Let’s see how this works using the example of a digital camera SoC.

This SoC contains multiple IP blocks that must cooperate to execute real-world application scenarios. The yellow arrows in the block diagram show one such scenario: viewing a previously saved photo. The SD card controller reads a JPEG-encoded photo from the SD card where it had been saved and stores the image into memory. The photo processor reads the JPEG photo from memory, converts it back into a raw bitmap image, and saves the result to memory. The display controller reads the raw image from memory and displays it on the phone display for the user.

The design and verification team for an SoC typically think of the chip’s operation in terms of the data flow. The flow for the application scenario of displaying a saved photo can be expressed as follows:

The data flow is shown from right to left because this makes it easy to convert this diagram into a graph readable by Trek Soc.  The flow arrows are reversed to show the prerequisites to make outcomes happen, yielding a graph as follows:

In the case of this scenario, the outcome involves displaying an image for the user. TrekSoC can read this graph and work backwards to solve the complete chain of events that can produce this outcome. The display image comes from the display controller, which in turn takes its image from the photo processor, which takes its JPEG-encoded input from the SD card controller, which gets its input from the SD card.

Tags: Breker, constrained-random, EDA, functional verification, graph, scenario model, test generation, TrekSoC, uvm

This entry was posted on Tuesday, July 23rd, 2013 at 12:03 am. 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.