The Power and Simplicity of Path Constraints

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:

This is still not a very complicated graph, but there are a fair number of ways to traverse it:

• The SD card controller can write out a raw photo or video from either of the cameras, a JPEG file, or an MPEG file
• The USB controller has exactly the same options available as the SD card controller
• The display screen can show the current raw photo or video from either camera, a raw photo or video read from either the SD card or the USB port, a JPEG file converted back to a raw photo, or an MPEG file converted back to a raw video.
• The photo processor can convert a raw photo from either camera to a JPEG file or convert a JPEG file from either the SD card or the USB port back to a raw photo
• The video processor can convert a raw video from either camera to an MPEG file or convert an MPEG file from either the SD card or the USB port back into a raw video

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.

Tom A.

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

This entry was posted on Wednesday, May 25th, 2016 at 6:19 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.