Total Value Of A Standard

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.

At the DVCon Portable Stimulus tutorial this year, several members of the audience asked why two languages are being created. The simple answer to this is that participants of the standardization committee voted for two languages and much of the desire for the inclusion of C++ came from the user community. That in itself is a good enough reason to include it. They are going to be the users of it and we, as a community, need to provide them with what they say they want, not what we think they want.

Given that there will be two languages, it makes a great deal of sense to have both of them designed within a single committee at the same time. EDA seems to like two-language solutions. Think about Verilog/VHDL, UPF/CPF, SystemVerilog/e or SystemVerilog/SystemC. In each case, there are difficulties translating between them because they have different underlying semantics. By defining the two languages together, that issue is avoided and market forces can decide which one is better.

Does this mean that you will have to decide which tool to buy based on which language has been implemented in a tool? In the case of Portable Stimulus, vendors don’t get a choice. They have to implement both or they don’t adhere to the standard. We can imagine, as was the case with SystemVerilog, UVM and other standards, that vendors will not implement the entire standard when it is first released. However, the industry will quickly force vendors to complete their implementation or they will fall by the wayside.

With that off the table, it comes down to looking at the value that each language provides.

The industry standard language that will become part of PS is C++. This language has existed for a long time and has a vast community of developers working on it. It is mature and has well-defined execution semantics. It is also a language that is in common usage within the community that will be using PS. It is important to identify this community because PS is not targeting hardware engineers doing implementation. They will continue to use SystemVerilog for the foreseeable future. It is targeting software developers, system-level integrators, architects and chip bring up engineers. Many are already C or C++ users. But language familiarity is not the most important issue here. It is that these users have libraries of code already developed in C or C++ that can easily be integrated. It provides them with an easy migration path.

Figure 1: Performing a data read using C++ in Portable Stimulus

The ability to integrate existing code bases relies on well-defined interfaces. Those already exist for C and C++ and not only to libraries in the same language, but to others such as MATLAB, often used for the development of reference models. C can call anything, including Pearl, TCL and all of the other languages in use within the design community. The first generation of PS will not have any interfaces defined directly from the domain-specific language and thus the C++ version will be the only way to incorporate legacy code. Every EDA-defined language has eventually had to provide an external interface, often to C, to enable user control and extensibility as well to provide the extensions to the language not conceived when the language was developed. This issue has been averted by incorporating C++ into the standard.

Also remember that portable stimulus is likely to be generating code that will be compiled and run on the processors of the design. The fewer times that code is translated or manipulated through interfaces, the more likely it is  to have “clean” code and that it will run true to its original intentions. That will make debug a lot easier.

If C++ is the standard, then you might ask why we even need Portable Stimulus. Why can’t we just develop the code in Eclipse or some other code development platform? You could potentially, but that would be equivalent to writing all of your existing testbenches in SystemVerilog and not utilizing UVM. There is another big difference in that the C++ code is not executable in the same way as it would be if you are writing a program. It is a model interpreted by a tool that will generate a testcase. You would still need a tool to take your handwritten C++ code to perform that function and that is the primary value of the PS tool.

Breker has pioneered the C++ direction for many years based on the feedback we obtained from users. We understand your problems and having the C++ option will provide you with a more powerful solution that fits your needs both today and in the future and that maximizes the total value of the standard. We will also be happy to implement the domain-specific language when it gets defined. Together we can do this.

Tags: Breker, C++, industry standard language, portable stimulus, PSS language, SystemVerilog, two-language solution, user community, uvm

Category: Knowledge Depot

This entry was posted on Monday, May 22nd, 2017 at 11:51 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.