Easing Your Way into Portable Stimulus

The Portable Stimulus Standard (PSS) was officially released at DAC this year. While it will no doubt continue to evolve, for those who were waiting on the sidelines, it is officially safe to start testing the water. In fact it’s probably been pretty safe for a while; vendors have had solutions out for some time and each is happy to share stories on successful customer pilot projects. And I’m told they’re all lined up with the released standard.

That said, PSS obviously isn’t mainstream yet. According to Tom Anderson, who provides marketing consulting to a number of companies and has significant background in this domain, you might think of PSS adoption today as not so different from where formal verification was ~10 years ago – early enthusiasts, pilot projects, likely more innovation and evolution required before it becomes mainstream.

Different people probably have different takes on PSS but for me the motivation isn’t hard to understand. SoC verification engineers have been screaming for years for a way to better automate and accelerate system-level testing while driving better coverage and better reuse of verification components. PSS is what emerged in response to that demand.

Some were upset that PSS wasn’t just an add-on to UVM, but this shouldn’t be too surprising. We’ve already accepted that we need multiple different types of modeling tool – from virtual prototyping to formal verification, software simulation, emulation and FPGA prototyping – because the verification problem is too big to be managed in just one tool. The same applies to verification methodologies – from ad-hoc testbenches to UVM to PSS – because, again, the verification problem is too big to be managed in one verification methodology. UVM is great for the block/IP-level task, but if you’re an architect or a full-system verifier, you’ll probably welcome PSS as a platform much better suited to your needs.

Still, new languages undeniably create new learning curves. For a variety of reasons, PSS comes in two flavors – C++ and Domain-Specific Language (DSL). Demand for C++ unsurprisingly evolved from the software folks. DSL as I understand it is designed to look more familiar to SV users. This split may seem unnecessarily fragmented to some but remember the range of users this has to span. I’m told the standard has been tightly defined so that features in each use-model are constrained to behave in the same way.

PSS adds another wrinkle – it’s declarative, unlike probably most languages you’ve worked with, which are procedural (C, Perl, Python, SV, UVM, …). In a procedural (test) language, you describe how to perform a test; in a declarative language you describe what you want to test and let the tool figure out how. Constrained random does some of this, but still heavily intermixed with details of “how”. Declarative languages such as PSS go further, making test development easier to reuse but also making thinking about test structures a bit more challenging.

So given this, if you want to experiment with PSS, who you gonna call? The simulation vendors of course for compilers / constraint solvers / simulators. They also provide nice graphical tools to view task graphs and generated paths through those graphs. But if history is any indicator, many verification engineers aren’t big fans of graphical creation tools. Most of us prefer our favorite text or “studio”-like editors which may provide additional support for class browsing, autocompletion and similar functions.

AMIQ recently added support for PSS in the very rich range of design languages they support through their Eclipse-based integrated development environment (IDE). This provides on-the-fly standard compliance checking, autocomplete, intelligent code-formatting, code and project navigation through links, search, class-browsing and integration with all the popular simulators and revision control systems. The figure above shows DVT Eclipse DVE offering an auto-completion suggestion to fix a detected syntax error.

AMIQ supports both C++ and DSL users. Tom tells me that each finds different value in the tool. For the C++ users, the real benefit is in class library support. For DSL users, that the language is close to SV is both a plus and a minus – it’s familiar but also it’s easy to make mistakes. On-the-fly checking helps get around those problems quickly.

Tom wrapped up by acknowledging that in PSS, everyone is learning; there are no experts yet. You can choose to learn quickly in an IDE or you can choose to learn slowly, alternating between your editor window and the LRM. I know, I’m just as bad as everyone else in wanting to stick to my favorite editor, but maybe there’s a better way. You can learn more HERE.

Also Read

CEO Interview: Cristian Amitroaie of AMIQ EDA

Automated Documentation of Space-Borne FPGA Designs

Continuous Integration of RISC-V Testbenches