Constrain Me, Please

In the movies, when a person acts irrationally they are usually declared to be mad and quickly placed in a straitjacket for the protection of themselves and those around them. If we continue those thoughts into the world of verification, SystemVerilog must be declared to be a mad language.

The problem is that the language designers did not understand the power of constraints. The only notion of constraints it has is simple combinatorial constraints on a single input vector. This is why many of the tests generated from SystemVerilog are irrational because they cause no useful function to be executed in the design. Those irrational tests have to be identified and discarded, a process that is highly inefficient and ineffective.

UVM attempted to help a little with the creation of sequences. These attempt to add a notion of sequential constraints by identifying prebuild legal snippets of directed test that could be used in the creation of larger tests. They help, but this is still not enough and they suffer from several other problems.

When contemplating true system-level verification, the targeted state space is many orders of magnitude larger than SystemVerilog ever contemplated. Without a complete set of constraints built into the language, the user will again have to suffer from the same type of inefficiencies.  Thankfully, a number of constraints are naturally contained within a graph-based language, but more are required to ensure that all test scenarios produced are both legal and useful.

In this blog, we will look at the variety of constraints that can and should be applied to graphs. These include notions of coverage, priority, dependence, resource limitations and sharing.

A verification intent model defines all of the possible paths through a design, but not all paths may be valid based on past actions. For example, after an action (A) has been performed, it may not be possible for A to happen again until another action (B) has been completed. Thus the sequence AA is not legal even though a graph may show them to be independent choices. This kind of constraint has been discussed at length in previous blogs which you can find here and here.

Another form of constraint is priority. After an action has been performed, several other actions may be possible but some may either be more probable or more important than others. Thus decisions need to be weighted. Coverage plays a part here. The weighting may be altered by certain sequences having already been verified and thus have lower importance until all combinations have been tried at least once. Coverage is directly supported by graph-based models (We will discuss this in detail in a future blog) and thus problems associated with closing coverage holes will become a lot simpler.

But there is another level of constraints that become important when we start to consider more complex scenarios. At the system-level, multiple things can be happening in a design concurrently, and if we are to verify aspects of performance, or power consumption, then the creation of stress tests is an important aspect of verification. This means that the scenario generation tool is not attempting to find a single path through the graph; it is attempting to find multiple simultaneous paths. This requires a completely different kind of constraint, one that begins to look a lot like the system architecture. How many processors are available, how much memory, what communications constraints exist? There is no point generating a test that cannot actually run on the system and that means tasks have to request the necessary resources and be scheduled. If there is insufficient memory available for a particular task to proceed, then it may have to wait until the memory becomes available.

Breker has been discussing these types of constraints with customers for several years and has developed ways in which they can be defined within the graph. It is important that these become part of the Portable Stimulus standard, otherwise we will regress back to the creation of another mad language without the necessary means to constrain it, and that means lots of irrational scenarios that you will have to pick through. We would love to hear how important these kind of constraints are to you and thus by implication how important you believe system-level constraints are in the creation of the PSS. Together we can do this.

Tags: Accellera, Breker, coverage, graph-based, path constraints, performance, portable stimuls, Portable Stimulus Standard, power consumption, resource limitations, stress tests, SystemVerilog

Category: Knowledge Depot

This entry was posted on Thursday, December 8th, 2016 at 6:27 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.