One of the great things associated with the development of a standard, such as the Portable Stimulus Standard (PSS), is that it brings together various stakeholders – often a broader selection of people than any single company did business with. When you initially develop a product you gear it toward a particular problem, one that you have some familiarity with. The resulting product attracts engineers who resonate with the product and they provide valuable feedback. This in turn helps to make the product more attractive to engineers with a similar need. If you are not careful, you can have a product that targets a narrow part of the market and that is all you learn to explore. It is the Innovators Dilemma, and can stop a company from developing a general purpose product. (more…)
Posts Tagged ‘SystemVerilog’
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. (more…)
Accellera has just extended the review period for the Portable Stimulus Standard. The committee is now seeking comments up until the end of October. Breker would like to join the committee and say how important it is for users to get involved with this standard. While we, as vendors, have some experience in this area, we are not doing this day in and day out. We need your guidance and feedback.
Breker applauds Mark Glasser, principal engineer for NVIDIA, for being a user who is spending the time and effort to understand the emerging Portable Stimulus Standard (PSS). The points he raised in his recent blog are shared by a number of other users in the industry. His passion comes from the fact that he sees the potential of the work that is being undertaken and the impact that it could have on the verification community and the entire system development flow.
Users are, by definition, those in the trenches experiencing the problems and trying to find solutions. Within that community, there are only a few that can see beyond the current design and can look towards the future. Of those, only a precious few can help to influence the direction of the future. If you are one of those, then we ask you to get involved. Sitting on a standards committee can be tough and often dirty work, but there is no better way to guide the future direction of the industry.
We share Mark’s feelings that we should leverage the extensive expertise that exists in the language design community. It has taken many hundreds of man years of effort to get C++ to where it is today and we have seen, during our interactions with users, the power and flexibility that C++ provides to this problem.
The creation of the Portable Stimulus standard has raised a number of issues about the tradeoffs between using an industry standard language and a domain-specific language. Several blogs have tried to make the case for one or the other and often use scare tactics to make one look better than the other. That is not the objective of this blog. Instead, it’s meant to provide some information as to why the inclusion of the C++ variant is a good thing for the industry. (more…)
When people think about design languages, they may not realize that the language is almost irrelevant. The language supports the underlying semantic model and it is this model that is important. EDA has defined design models at the gate level, the register transfer level (RTL) and various forms of behavioral levels. When we talk about RTL, we think about Verilog and VHDL, but they are only the languages that support that model, or very minor variations of it. But what about verification? (more…)
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. (more…)
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.
With a nod to Mark Twain, this week I’d like to comment on a recent three–part series with the provocative title “Are Simulation’s Days Numbered?” The articles were transcribed from one of the “experts at the table” events that SemiconductorEngineering does so well. Breker wasn’t involved in this particular roundtable, but I enjoyed reading the series and found that it stirred up some thoughts. As a blogger, of course I’m going to share them with you and I hope you enjoy them in turn.
Let’s get this out of the way immediately: in three parts and more than 5,000 words, there was no mention of portable stimulus. That might not seem too surprising given the title, but in fact verification portability both from IP to system and from simulation to hardware arose during the discussion. So I’ll comment on that but, given my background as a vendor of formal EDA tools and reusable IP blocks, there are a few other topics that also piqued my interest.