Solution = Standard + Tool

Solutions are what users need and the existence of a standard gives them the assurance that models they create will be portable between tools. Put another way, the standard creates a level playing field on which vendors can create tools that provide solutions.  When the standard is lacking, deficiencies can be made up for in the tools. One example is path constraints that can be used to constrain the sequence of actions used to create a scenario, rather than combinatorial constraints which constrain numerical values. An example could be that after a burst write, you cannot have another write. This is a capability that Breker tool users have had for many years and one they do not want to see go away with the creation of the Portable Stimulus Standard. In the Early Adopter release, only a very rudimentary form of path constraints was offered and users have expressed their concerns about the adequacy of that proposal.

Breker users will not have to lose this capability even if the first release of the standard does not provide it, and it will not damage the portability of their models. However, if they switch to tools from vendors that do not provide this capability, they may have to do extra manual effort to eliminate erroneous testcases and they may have fewer options available to them to perform concentrated verification.

Let’s start with a simple example as shown in Figure 1.

Fig 1: Simple portable stimulus graph

This graph contains two producers and two consumers joined by the data type ‘S.’ The DSL description for this is shown in Figure 2.

Fig 2: DSL description of graph

This graph has four possible paths: producer 1 feeding consumer 1 and 2, and producer 2 feeding consumer 1 and 2. Now, let us consider that one of those paths is not valid. This is shown diagrammatically in Figure 3.

Fig 3: Path constraint on graph model

The early adopter version of PSS defines that this can be achieved by manipulating S such that producer 1 cannot supply consumer 2, leaving only three valid paths through the graph. This solution is acceptable for a trivial example such as this, as long as this is a restriction for every instance of this graph when incorporated into a larger graph. In other words, the solution only works if the constraint exists directly within the graph model and is not influenced by how it is used. If the constraint only exists in one instance of the graph, then it is unacceptable to have multiple variants of the graph, each with different constraints embedded in them. This destroys the goal of model portability, which is foundational to the standard and would create problems when the graph is reused in another project requiring a different set of constraints. Keeping track of such constraints would be a nightmare.

There are several situations in which a path constraint is better overlaid onto a model rather than incorporated into it. An example may be a path that exists at the system level. Perhaps the architect has determined that it is not an efficient path and will be excluded in software. For the purposes of verification, creating tests that activate an illegal or undesirable path will be a wasted effort. There may be cases where particular paths are known to have problems or that the hardware implementation of them is not yet complete and thus early tests should avoid them. These paths may be complex and span many sub-graphs. Modifying the models could end up being more onerous than creating them afresh, thus defeating the purpose of reusability.

Another use of path constraints is to guide the testcases that are generated. If a verification team wants to concentrate on certain areas, they could use path constraints to close off parts of the graph no longer accessible to the generator. This in effect enables semi-directed testing leaving only desired options available to randomization.

How can we do this without compromising model portability? One potential solution, in common usage by the industry, does a similar thing for power intent. The functional model is written in SystemVerilog and the power intent is described in a UPF file that overlays the functional model. If the first release of the standard does not provide a full solution to path constraints, this is the approach that Breker may take. Paths through the graph can be identified in the user interface and these act as a guide for the testcase generator/ tool from Breker. The model does not need to be modified to do this.

Breker hopes that a full solution to this will be incorporated into the first version of the standard. Of course, tools will be able to layer capabilities on top of models and this is one of the ways in which vendors will vie for the attention of users. We will highlight other ways in which we will be doing this in future blogs. Breker is fortunate in that we have been working with users for over a decade and understand many of your toughest problems. We hope that we know the solutions that you require and will work hard to find ways to keep them available to you as the industry transitions to Portable Stimulus Standard. Together we can do this.

Tags: Breker, DSL, early adopter release, path constraints, portable stimulus, PSS, SystemVerilog

Category: Knowledge Depot

This entry was posted on Thursday, November 30th, 2017 at 4:16 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.