The Making of a Standard

The industry waits with bated breath for the Accellera board to approve the Portable Stimulus 1.0 specification. It has been a long and arduous process over the past four years to get to this point, a process that most people never get to experience. This was my first standard, and to say it was an eye opener is somewhat of an understatement. In this blog, I am not going to dwell on the many bruises I suffered or the technical discussions that often seemed like personal attacks. Instead, I want to make the industry aware of some of the difficulties associated with bringing a new and somewhat revolutionary standard to market.

Breker has been making tools in this space for more than a decade and that presents the first, and very scary, hurdle for a startup company. For most of the period, before the creation of the standards group and throughout its development, we only had one major competitor and they were a much larger company than we were. Would getting the standards process going help us or hinder us?

You may wonder if the market or the technology is ready for a standard and will that accelerate or slow down the rate of innovation? At Breker, we went through several generations of our technology. Each time, we refined the concepts, expanded the scope, improved the capability of the tools or addressed limitations when they were found.

Many industry watchers think that companies and development groups should wait for a standard to naturally emerge rather than create one in committee.  Mentor decided the issue by starting a taskforce within Accellera to study what was called Portable Stimulus. And, that is where the games began!

To get Accellera to approve the formation of the committee took a little bit of subterfuge. Accellera already had committees looking at verification languages and constrained random verification. They were well populated and had achieved significant levels of success in the market and would not endorse a new language or new methodology that competed with them. To get approval for the committee to be formed, it was reasoned that this new approach would solve a specific problem:  moving stimulus from simulation to emulation. With existing solutions, this was difficult and resulted in duplicated effort. Thus, the name Portable Stimulus was etched in stone, something that everyone involved now regrets. The standard is not really about stimulus. It is about verification, of which stimulus is a small part, and the stimulus created by a tool that is driven from a Portable Stimulus description is not portable.

The committee was officially formed in February 2015. It was expected by some committee members that getting a standard out was going to be quick and easy. That was before step one was started, which was to assemble a list of requirements from participants. Many user companies got involved and it became apparent that each had slightly different requirements, some substantially different than what vendors knew. This changed the work of the committee from being the standardization of something that fully existed into a process of learning what was required and developing the right solution.

Over the course of the next three years, work progressed, but some demands changed during that period. The development of Portable Stimulus, like other standards was, in some respects, chasing a moving target. In addition, committee members came and went, and new members often had different ideas.

The committee had to consider when to stop to incorporate those ideas that may mean taking a step back. The makeup of the committee also changed. Initially, it was dominated by technical people. Later marketing and product managers  got involved  with different ideas about what should happen.

We hit a point when a difficult question needed to be answered – which features to include for a 1.0 release and what gets left behind, with a promise that it will be addressed in the next release. This is never easy. Include too much and the standard never gets it out of the door. Include too little and the standard may not be valuable enough or capable of solving a large enough set of problems.

Many times, those extra features are never fully addressed because:

1. a) they were too difficult
2. b) things are now set in stone that makes changing or incorporating anything twice as difficult as it would have been without destroying backward compatibility

As soon as the standard is released, vendors will be busy getting everything implemented and when users find issues they will be busy trying to make what they have fully work. Additional capabilities only become important when users mastered the ones already there or when they push hard enough for additional capability to be added.

There is another contentious point with standards. Should standards be defined for what is required, or what vendors know how to implement today? At Breker, our technology is considerably beyond what is contained in the standard, and the standard has been limited to what other vendors know how to implement. The standard has become the lowest common denominator. Users who need capabilities beyond the standard lose portability, one of the primary reasons for creating the standard. However, users of existing proprietary solutions are unlikely to be satisfied with the limitations placed by the standard.

The creation of the standard changes a lot. At Breker, we already benefitted from the development of the standard. The creation of the standard levels the playing field and allows vendors to compete on technical capability rather than language.  It allows us to compete on the quality and capability of our tools. We no longer have to spend as much time educating people about the value of the approach because that cost is now shared by all of the vendors and Accellera. It lowers the barrier to user adoption. No longer do they fear being stuck in a proprietary language and flow, especially when dealing with a startup. With a standard in place, part of the fear is removed because they should be able to migrate the models they have developed to a different vendor. While that is not guaranteed to be easy, it is at least possible.

For me personally, the biggest takeaway is the strengthening of something I think is important – it is always more valuable to listen than to talk. We learned so much from users about how they want to apply the technology. We learned from users what we had not encountered until now because we were focused on a different aspect of the market. We learned from users about important features and capabilities rather than just the ones we knew how to solve. It helped to make us stronger and hope that our products reflect that. My team and I are available to chat more with you on this at the upcoming Design Automation Conference (“DAC”) In San Francisco, June 24 – 28.  Come find us at booth # 1419.  Together we can do this.

Tags: Accellera, Breker, dac, portable stimulus, Portable Stimulus Standard, PSS, verification

This entry was posted on Thursday, June 21st, 2018 at 7:02 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.