Dual Focus Will Help Adoption

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.

Thankfully, Breker never fell into this trap, as we tracked several groups of customers across various product segments. However, they all had one thing in common and that was their work in C or C++, included groups doing system-level testing, chip bring up, and hardware/software integration. Most of the time, they were hand writing tests, in C, that were executed on the embedded processors in the hardware product. It was important to them that the tools supported this language and thus we pushed hard for its inclusion into the standard. There were other users, particularly those struggling with verification problems that were not easily solved using SystemVerilog, who wanted a different language, one more tailored to the existing verification flow. Thus the committee decided to support two languages that can be used to describe the model of verification intent. When you couple Breker’s depth of over 10 years’ worth of experience with C++-based solutions, with the breadth of viewpoints present in the standards committee, the results can be far reaching.

Users coming from the mainstream verification task have lots of experience with SystemVerilog and UVM. These verification teams are trying to extend methodologies designed for block-level verification, which contained no processors, into full SoC verification. It is a monumental task and one has to applaud how well they have done with a language ill equipped for the task. SystemVerilog added constructs that were specific to the verification of hardware and made restrictions that allowed tools to be made more efficient. The definition of SystemVerilog borrowed many constructs from an industry tested and standard language such as C++, including object oriented notions. That same argument can be made for PSS and this is why the domain specific language (DSL) should be a natural extension of SystemVerilog and C++, which provides the user an easy path of migration.

Breker is known for being the leader in the development of the C++ version based on our depth of knowledge and experience with that class of user. We also acknowledge that there are a great many SystemVerilog/UVM users who may are not as familiar with the strengths associated with the C++ approach. They want the easiest possible path to extend into the usage of PSS while maintaining aspects of their existing methodology. For these users, a DSL makes sense. In order to minimize the learning curve and maximize ROI, they should not need to learn a completely new language when the PSS DSL could borrow from SystemVerilog.

The industry chose a two-syntax approach for a good reason. Users will be migrating from existing solutions who want to retain the knowledge and expertise they already have and they want the easiest possible path to create models. For some that will be C++ and for others the DSL. In our experience, the companies creating the most complex system level tests need the full power of C++. We thus expect to see many existing UVM users first adopt the DSL, but over time will want to start including the more advanced capabilities that will come from the usage of C++. Having both languages share a common inheritance will be a great help. It is also likely that teams will be made up of both types of users. As soon as one group builds a verification intent model, using either C++ or DSL, it can be used by all applications based on the standard. Allowing both to be freely intermixed will increase the rate of adoption and make sure that the standard does not focus just on a single application.

The creation of a standard is a learning process for everyone involved. Breker has taught members of the committee about a top-down approach to the problem, based on the knowledge gained from our customers. We learned from other members of the committee about a bottom-up approach and this is one that we are willing to fully embrace – except we believe that the existing DSL needs an improved approach. It must grow from SystemVerilog so as to allow existing users start from a familiar baseline. Together we can do this.

Tags: Accellera, C++, Dual Adoption, portable stimulus, PSS, SystemVerilog, uvm

Category: Knowledge Depot

This entry was posted on Wednesday, January 31st, 2018 at 9:58 am. 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.