Accellera’s Portable Stimulus Specification (PSS) answers a pressing need. Verification is reckoned to take up 70% of the design cycle and that challenge has been addressed by leveraging a variety of techniques. For all the good they have done, a big problem has been that a stimulus created in one realm (formal, emulation, FPGA prototyping, etc) has not been easily translated to another. PSS tools generate tests that can work across those platforms.
The objective behind PSS, and how it addresses not only verification platforms but also the design hierarchy, is shown in Figure 1. It directly targets a long-standing limitation in UVM-based testbenches.
However, the PSS has still needed to incorporate two different input methods, as a new position paper from Mentor, a Siemens business, explains:
“From the early days of the [Portable Stimulus Working Group], it was apparent that trying to satisfy a wide range of users with a single input format would be difficult.
“Hardware designers and block-level verification teams use SystemVerilog as the primary language for both design (with a synthesizable subset) and verification. Concepts such as constraints and biasing were familiar from the UVM and constrained-random stimulus technologies, so it was natural for engineers to expect that these capabilities would be included in the PSS.
“On the other hand, most validation engineers using hardware platforms write code for embedded processors in C, with a few using C++ or other object-oriented languages such as Java. They were generally unfamiliar with constraints and other verification-related language features.
“Chip-level verification engineers typically sat in the middle, writing SystemVerilog for their UVM testbenches while writing embedded processor code in C. C++ was not commonly used except in conjunction with the SystemC class library to create ESL models. “
So… decisions, decisions. Which input language should you use? The self-explanatory PSL-C++ or the SystemVerilog-led PSS-DSL?
The good news is that there is interoperability to allow a project to mix and match models in the two different formats. Every engineer will therefore be able to remain in his or her comfort zone.
However, Mentor is proposing that you opt for PSS-DSL where a choice does need to be made. A key issue is verbosity. PSL-C++ is more wordy for both class declarations and declarations of random feeds, the company argues.
“Conciseness is only one measure of an input format or language, but it is an important one. Concise, clear syntax is easier to learn, remember, and type,” Mentor argues.
It further suggests that engineers who have a C background may still find the move to PSS-DSL easier – or at least one that presents as steep a learning curve. And in terms of capability, the two input formats are equivalent.
You can take a deeper dive into Mentor’s position by downloading the position paper, ‘Choosing a format for the Portable Stimulus Specification’.