There is an important standard being worked on within Accellera and given its name, you might think that this is another incremental standard on a somewhat tired theme. It is called Portable Stimulus and yet it has almost nothing to do with stimulus and that stimulus, once generated by a tool not defined in the standard, is most certainly not portable. It is a fundamentally new approach to verification that could transform how chips and low-level software are verified. We will get back to the name in a moment, but the important thing is that users become informed about this new language and choose to have their voices heard in the standardization effort.
Posts Tagged ‘testbench’
As some of you may have seen, two years ago the IEEE created an app that ranks the popularity of dozens of programming languages. They use twelve different metrics, from search results and social media mentions to technical publications and requirements listed in job openings. If you don’t like the way that they use these metrics, you can create your own ranking using your own mix. It’s really quite a clever idea and it generates lots of discussion every year.
For 2014 and 2015, C held the #2 spot, just below Java in the rankings. The big news this year is that C has edged into first place, although the top two spots remain very close as measured by the metrics the IEEE has chosen to use. C++ was in the #3 spot for the past two years, but for 2016 flipped places with Python. As you all know, we are strong advocates of C/C++ for verification and so we’d like to share some thoughts on these results and what they mean for our industry.
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.
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.