The Breker Trekker
Tom Anderson, VP of Marketing
Tom Anderson is vice president of Marketing for Breker Verification Systems. He previously served as Product Management Group Director for Advanced Verification Solutions at Cadence, Technical Marketing Director in the Verification Group at Synopsys and Vice President of Applications Engineering at … More »
Verification Beginning with the End in Mind
July 23rd, 2013 by Tom Anderson, VP of Marketing
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.
There may be multiple outcomes and many possible scenarios, each with its own path through the graph. For each test case, TrekSoC picks one such path and generates the C code and input values needed to execute it. For a multi-threaded or multi-processor design, TrekSoC generates test cases with multiple scenarios running concurrently in order to really stress-test the chip. The complete graph-based scenario model captures all possible SoC behavior so that TrekSoC can fully exercise the design.
As you can see, TrekSoC indeed begins with the end in mind when generating test cases. Again, this is a closed loop system. If you specify a particular node on the graph, or a particular path through the graph, TrekSoC is guaranteed to produce a test case that will trigger the requested behavior. No testbench-based verification approach can do this. Future blog posts will discuss the implications of this for coverage as well as the many ways that you can influence how TrekSoC runs on the graph and generates its test cases.
The truth is out there … sometimes it’s in a blog.