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.

(more…)

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.

(more…)