Can Portable Stimulus Be Saved?

Do you remember the programming language Pascal?  It was first published by Niklaus Wirth in 1970, and was quite popular in the late 70s and early 80s.  At that time C was not the de facto standard programming language that it later became.  There was a lot of excitement about Pascal, as it was a modern language in way we think of them now, and it was a huge departure from the likes of Fortran and Cobol.  It was the wave of the future.

Pascal can trace its heritage to Algol (as can C and Java) with its block structured constructs, call-by-value and call-by-reference semantics, and strong typing.  Pascal source code compiled to an abstract assembly code called p-code.  This offered the potential for code to be highly portable across machine architectures.  The application code itself did not need to be ported, only the p-code machine.

While there are still people writing Pascal, it did not become the go-to language (no pun intended) for large-scale industrial applications.  The TIOBE index shows it as the 4th most popular programming language in 1987, and the 112th most popular in 2017.  What happened? Why did it not make the transition into the world of industrial grade applications?

There are many reasons Pascal did not make the cut.  Certainly among them is the lack of a general purpose pointer and overly strong typing.  These made it near impossible to deal with real world situations where data is not always as constrained as you might like.  Most likely the final death blow was a paper written in 1981 by Brian Kernighan, one of the inventors of the C language, titled "Why Pascal is Not My Favorite Programming Language." In that paper he blasts Pascal, eventually calling it impotent. His conclusion in the paper is "In its pure form, Pascal is a toy language, suitable for teaching but not for real programming." Various dialects of Pascal have since introduced type casting similar to C, but that's not where the standard was in the 1980s.  The bottom line is that the language could not make the leap from academia to industry.  It was not up to the task of building large-scale applications.

The emerging Portable Stimulus Standard (PSS) as described in the Early Adopter release of the standard is in a similar state. While its foundation is based on some great ideas, it does not have all the elements to make it a language for use in a production environment. System-level tests for complex SoCs are themselves complex pieces of software that can include multiple layers. The medium used to code those tests must be able to support that kind of complexity.

Let's start with one of the more obvious deficiencies -- lack of parameterization.  The notion of portability implies reuse.  Without parameterized elements it's difficult to make code reusable or portable. Parameterization is a way to deal with changes in environments or changes in design characteristics.  Without any way to supply parameters and distribute them throughout the test full portability and reuse cannot be realized.

Another elephant in the room is lack of proper support for user-defined data types. PSS provides structs as an aggregation of scalar data objects.  However, it does not provide a way to create an abstracted interface for those objects.  Every assignment, constraint, or computation is done only at the lowest level.

Without any kind of function abstraction and no reference object (i.e. handle or pointer) it is impossible create polymorphic objects, resulting in another reuse limitation.  Creating families of classes derived from an (abstract) base class is an important way to implement core functionality which can be reused in a number of different situations through a derived class.  The PSS allows object extensions to add to an interface, but not to override the base interface using virtual functions.

Patterns are abstractions that contain a collection of related classes instead of a single class. Object references, virtual functions, and user-defined data types are means for building patterns and higher level abstractions.  These are fundamental elements of reusable software and are noticeably absent from PSS.

On a more pedestrian level, include files and a macro preprocessor are missing from PSS.  Text preprocessing is an important part of building real world applications.  Include files are important in sharing large-ish chunks of code without copy/paste.  Macros are useful for sharing small, tedious pieces of code or code fragments that must appear in many places.  They can also be used to smooth over any number of ills in creating an API.

Besides omissions, there are some things in the language that raise concern about whether the language is suited to industrial application.  For example, hierarchical references are used to connect objects in different components.  Simply put, this is not a good idea.  Think about out-of-module references in Verilog, sometimes called OOMRs or XMRs.  They create a maintenance headache, and their use is the bane of every team responsible for any significant chunk of Verilog code. They make the hierarchy fragile. Modifications of the hierarchy often require XMRs to be modified, usually by hand. In PSS the problems will be no different.

Another worry is the coverage model.  It's admirable that the PSS contains a way for collecting functional coverage information. The problem is that it's different than the model in SystemVerilog for collecting functional coverage.  Perhaps one could argue the PSS version is better. Perhaps not.  The point is that the two are different.  When preparing a system-level coverage model do you create it using the SystemVerilog style, or the PSS style?  Can the two be reconciled.  I'm sure this greatly annoys the tool vendors who likely wish to support both.

This list is not complete, but it should give you the sense that the PSS as currently defined is not ready for prime time.  It has significant structural flaws that prevent it from being used in real-world production environments. 

Recently I wrote about Why You Should Care About Portable Stimulus, in which I noted that "The PSS represents the first germ of the next abstraction level available in an industry-wide standard form."  This is an important thing, but the next abstraction will emerge eventually from some source.  Accellera has the industry visibility to enable a new standard and new ideas contained in that standard to gain traction relatively rapidly.  However, Accellera has no monopoly on disseminating new ideas.

Can PSS be saved?  Perhaps.  It will require the PSWG to roll up their sleeves and dive into all of the nitty-gritty details required to build a real language. It will require the verification community to support the work of the PSWG by providing feedback on the PSWG's work. It will require investment by those interested in a successful outcome -- e.g. companies providing qualified volunteers to contribute to the PSWG's efforts.

The comment period for the Early Adoption version of the Portable Stimulus Standard closes on September 15, 2017.  Please take the time to offer your comments on the Accellera website.

PSS can be saved if the PSWG takes seriously the idea of building a real language and not a toy.  If they do not, then the PSS will suffer the fate of Pascal.  It will enjoy a brief moment in the sun until people learn that its flaws outweigh its strengths.