An Important Next Step for Portable Stimulus Adoption

Portable stimulus has been a hot topic for a couple of years in the EDA and semiconductor industries. Many observers see this approach as the next major advance in verification beyond the Universal Verification Methodology (UVM), and the next step higher in abstraction for specifying verification intent. The basic idea is to create high-level models that can be used by EDA tools to generate test cases automatically. Yes, that sounds rather like the sort of constrained-random simulation tests supported by SystemVerilog, and even longer by the e language, both well-established standards. Let me explain what’s new.

Note first that Portable stimulus is also standardized; Accellera released version 1.0 of the Portable Stimulus Standard (PSS) at the Design Automation Conference (DAC) last year and version 1.0a in February to clean up a few things. But PSS is different from SystemVerilog and e in at least three important ways. I already mentioned the higher level of abstraction, and this enables the portability at the heart of the other two differences. PSS tools can generate test cases that scale from block/IP level through subsystems to complete SoCs/systems, and also from simulation through emulation, prototyping, and actual chips.

A recent post by Jim Hogan provides lots more information on the history and goals of portable stimulus and the standard. It’s easy to see why there’s so much interest in his topic. The idea of writing one abstract, portable model that can generate test cases for every phase of an SoC project is really attractive. I’ve talked with PSS tool vendors Breker, Cadence, and Mentor, and they all assured me that adoption is going well. There’s a fourth vendor in the PSS camp, AMIQ EDA, and my colleague Bernard Murphy discussed their initial support for portable stimulus in a post about six months ago.

Since then, I’ve had several interesting conversations with AMIQ EDA’s CEO, Cristian Amitroaie, about different aspects of their Design and Verification Tools (DVT) Eclipse Integrated Development Environment (IDE) and their Verissimo SystemVerilog Testbench Linter. Cristian mentioned that the initial support they provided for PSS in DVT Eclipse IDE has been expanded, so I talked with him about a key new feature: scenario generation and visualization. Their tool now has the ability to analyze the stimulus being specified in a PSS model and display possible scenarios that satisfy the abstract specification.

Why is this so interesting? For one thing, a large number of valid scenarios can be generated from a single PSS model. It’s not easy for the engineer writing the model to visualize the details of the scenarios that could be generated.  Sometimes there are multiple ways to “solve” a PSS model to generate valid scenarios, and some of them may not be at all obvious (or even intended). The ability to visualize detailed scenarios can be very helpful in terms of determining whether or not the abstract PSS model is correct.

Due to the degree of parallelism available in a modern SoC, there may be dozens of processors and other engines running code, numerous I/O ports sending and receiving data, multiple memories with multiple channels and multiple levels of caches, and a bevy of buses tying all this together. Effective SoC verification requires exercising all this activity simultaneously. PSS models and the testcases based on the generated scenarios have the power to do this, but again it can be hard to picture how this all works without solving for valid scenarios and displaying them. I asked Cristian what happens if their tool cannot generate a valid scenario. He said that DVT Eclipse IDE provides detailed information about the generation process to help users fix the PSS model.

It seems to me that this new solving and visualization feature is a natural extension to the other capabilities that DVT Eclipse IDE offers for PSS code. The tool can parse code and find a wide variety of syntax and semantic errors, including those detectable only when multiple models have been compiled together. It also provides quick-fix proposals, hyperlinks to jump to declarations and usages, context-sensitive auto-completion of PSS constructs, structural views for browsing type and component hierarchies, project database queries, rename refactoring, and source code formatting.

I’ve been convinced for some time that a powerful IDE can make learning a new language much easier and save time in common operations even for the experts. This is certainly true for AMIQ EDA’s PSS support in DVT Eclipse IDE. The language is still novel for many engineers, while features such as scenario generation and visualization benefit both new and advanced users. I’d like to thank Cristian for sharing his thoughts with all of us, and I wish you luck as you adopt PSS.

To learn more, visit https://dvteclipse.com/products/dvt-eclipse-ide

Also Read

With Great Power Comes Great Visuality

Renaming and Refactoring in HDL Code

I Thought that Lint Was a Solved Problem