Path Constraints for Graphs and Portable Stimulus

As engineers, we take great pride in defining our terms carefully and using them precisely to try to avoid ambiguity or confusion. Many engineering specifications start with a glossary of terms and sometimes even a taxonomy showing how they are related. Sometimes though, natural language being inherently ambiguous, we find that we have overloaded the meaning of certain words in a way that can lead to precisely the confusion we seek to avoid.

One such word is “constraint” because it is used in several different contexts in chip design and verification. In today’s post we would like to discuss path constraints on a graph-based scenario model. We will explain how they differ from other forms of constraints and why path constraints are essential for any portable stimulus solution, including the Trek family of products from Breker.

If you’re a verification engineer writing tests or testbenches, chances are that you think first of constraints as applied to values or variables. All popular testbench languages, from e through SystemVerilog and SystemC, include some form of value constraint. Suppose, for example, that you are verifying a network switch that inputs and outputs packets in a particular format. You might want to constrain the size of the data payload to be less than some value so that you can process lots of short packets rather than a few long ones.

The common term “constrained-random stimulus” captures this idea well; in the presence of a constraint, the testbench will place on the inputs to the switch only packets that meet the constraint. The data in the payload of the packets might be randomized, as might other fields, but the size of the payload will be constrained. The Universal Verification Methodology (UVM) and its predecessor methodologies are built on constrained-random stimulus.

As another example, if you are verifying a floating-point unit you may want to focus only on certain input values that stress specific areas of the design such as the rounding logic or the process of eliminating leading zeros in the mantissa. You could use input biasing,  often considered a form of constraint, to cause most of the inputs to take on specific values while  still allowing other values to be generated once in a while.

If you are a formal verification engineer, you tend to look at constraints somewhat differently. The goal of formal analysis is to analyze each assertion about the design being verified and either to provide that the assertion can never be violated or to generate an input sequence (counterexample) that shows how it can be violated. Formal constraints ensure that only legal input values and sequences are considered in this analysis. It is likely that producing a bad packet on the output or violating some internal assertion is considered a design bug only if legal packets are sent in.

If you’re an RTL design engineer, you likely think of constraints as rules fed to your logic synthesis tool to specify the area, timing, and power requirements you would like in the resulting gate-level netlist. But now we’re getting rather rather far from verification, so let’s reign back in and talk about path constraints. As you know well, the basis for Breker’s portable stimulus solution is a scenario model that captures verification intent in the form of a graph. Let’s turn to an example we have used in past blog posts: a digital camera SoC:

This simple graph shows all the possible ways that data can flow through the SoC. The SD card controller can write out a raw bitmap image from the camera or a JPEG file generated from the raw image by the photo processor. The display can show the current image from the camera, a raw image previously saved on the SD card, or a raw image produced by the photo processor from a saved JPEG file. At various times during the verification process, you may wish to focus on certain blocks in the design or combinations of blocks that provide specific functionality.

Path constraints are an easy and natural way to control which paths are considered when a portable stimulus tool is generating test cases by traversing the graph. For example, if you want to focus on verifying the photo processor’s ability to create JPEG files, you might set a constraint that any path through the graph must go through the photo processor encode node in the graph above. Then all test cases generated will involve creating JPEG files from camera images.

A path constraint will often involve a series of nodes rather than just one, and might prohibit rather than force a particular path. Suppose that you want to stress the overall functionality of the photo processor by writing a series of JPEG files to the SD card, reading them back, and displaying them. In that case, you might specify constraints that block any path directly from the camera to the SD card controller or from the SD card controller to the display controller. This trims out two edges in the graph:

This example shows how natural it is to use path constraints to control flow through a graph-based scenario model and focus the generation of portable stimulus on areas of highest importance at a given point in the verification process. However, this SoC is too simple to show the full power of path constraints. In our next post we will add some functionality to this design to make it more complex and show how path constraints are superior to value constraints for guiding graph traversal and test case generation.

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

Tom A.

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 Thursday, May 19th, 2016 at 2:03 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.