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 »
The Power and Simplicity of Path Constraints
May 25th, 2016 by Tom Anderson, VP of Marketing
Last week on The Breker Trekker, we talked about path constraints and how they differ from other kinds of constraints commonly used in SoC design and verification. Our whole approach to verification is based on graph-based scenario models, and constraints on the paths through the graph are a natural way to control how our Trek family of products automatically generates test cases. It’s easy to eliminate some paths, focus on others, or bias the randomization of selections. We believe that path constraints should be a part of any portable stimulus solution that meets the forthcoming Accellera standard.
We have heard some people in the industry argue that path constraints are not needed, and that value constraints would suffice. While we agree that value constraints are a familiar concept from the UVM and other constrained-random approaches, we do not feel that they are the best way to control the scenarios generated from a portable stimulus model. In today’s post we will expand on the example from last week and show how path constraints can handle a more complex design better than value constraints.
Our previous example was a simple digital camera SoC or, more commonly these days, the portion of a smartphone SoC providing camera functionality. Because it was such a simple design, there were only a few paths to consider at the top level of the scenario model. So let’s add a second front-facing camera for “selfies” and video chatting to complement the rear-facing camera for traditional photos. Let’s also include a USB interface in addition to the SD Card interface.
Finally, let’s add a video processor that can covert a raw series of images into MPEG or reverse the process, in addition to the photo processor that can convert a raw bitmap image into JPEG or vice-versa. Given this SoC, the graph might look as follows:
At different points in the verification process, you may want to focus on certain parts of the design or certain types of functionality. For example, suppose you had licensed a USB core from a reputable IP vendor but had a new design for the SD card controller. Therefore, you might choose for a time to focus only on paths involving reading and writing the SD Card port. With path constraints, you could simply specify that no test case generated could arise from a path through the USB read or write nodes.
How would you do this if you had available only value constraints on variables? It seems to us that you would have to define a variable visible to the USB write node and to the four nodes that feed data to it, then define constraints for this variable on all five nodes such that no pair could be satisfied. For a variable X, the USB write node might specify that X must be greater than 5 and the other four nodes might specify that X must be less that 3.
Since these constraints together eliminate all values, effectively all paths involving the USB write function would be eliminated. You would then have to do a similar step with a second variable for the USB read node and the three nodes that receive data from it. This approach seems to work, but it requires much more effort and far less intuitive than simply specifying that no path should go through the USB nodes.
If you wanted to avoid generating tests for a specific scenario, for example front camera images being converted to JPEG and written to the SD card, with path constraints you simply specify that no path should go through the series of nodes. With value constraints, you have to establish variables plus constraints on those variables at each step. In a more complex SoC with paths containing dozens of nodes, the advantages of path constraints over value constraints are even more clear.
Are you convinced? Do you know of a better way to apply value constraints to control paths through a graph-based scenario model? Any comments or suggestions are most welcome.
The truth is out there … sometimes it’s in a blog.
Tags: Accellera, application, Breker, functional verification, graph, graph-based, JPEG, MPEG, path constraint, portable stimulus, PSWG, realistic use case, scenario model, simulation, SoC verification, SystemVerilog, test case generator, testbench, uvm, value constraint