Never miss a story from Breakfast Bytes. Subscribe for in-depth analysis and articles.
One of the opening presentations at the recent DVCon was an Accelera-sponsored update on the Portable Stimulus and Test Standard (PSS...yes, the acronym doesn't quite match since "test" was added later).
The presenters were:
Tom is the vice-chair of the Accellera PSS Working Group.
For some background and history on PSS, see my earlier blog posts:
Cadence's product that supports PSS is called the Perspec System Verifier, or Perspec among friends.
PSS was created because it is very hard to do verification at the system level. We have UVM that we can use at the IP level where it is very effective, but once you start to have several IP blocks that interact is not enough. By "several IP blocks that interact" I'm thinking about something like a camera with a MIPI CSI interface, a DDRx memory controller, and external DRAM. Each of those can be individually validated with UVM, but to check whether there is too much bus contention, and how the timing works with slowish DRAM requires more. And that is before adding an MP3 player competing for the memory controller.
But typically, there is another complication, software. There is (almost) always a microprocessor or microcontroller running software and that has to be part of the system verification too. Before PSS this required manual coding and giving up some of the most powerful tools in our arsenal, randomization.
Tom's opening slide of the presentation was that creating sufficient tests is far and away the biggest problem in verification:
Tom went through a history of UVM, which I will mostly skip. One important observation is that moving from functional coverage to UVM meant that we moved from one piece of code per test to multiple tests per piece of code. In the same way as we went from assembly language to C++, and from gates to RTL, we need to go from UVM to something higher level...which of course is PSS. Just was with UVM, we want to go from a single specification to multiple tests, but without violating any system constraints. Plus, we want this to work even when the test is partially in hardware and partially in software.
PSS has the concept of a scenario, which is getting the SoC to do something, and we need to verify that it does indeed do the thing. The scenarios don't need to be generated manually, though. Instead, the constraints on the system are specified more or less explicitly, and then randomization is used to generate actual scenarios. Each scenario is guaranteed to be legal, it constrains specific actions, and also it constrains scheduling relationships between actions. By separating test intent from implementation, we obtain high-coverage test generation across the verification process with much less effort.
The generalized tool flow with PSS (and with Cadence's Perspec) is shown below.
The rest of the workshop was taken up with three detailed examples. The entire workshop was 2 hours, and each example was a couple of dozen slides, so it's not possible to compress it all into a single blog post. The three scenarios were:
I'll summarize the conclusions of the three examples. First, the display controller:
Memory and cache examples:
Tom came back on at the end to wrap up the workshop with a summary:
Download the PSS standard from the Accellera website.
See the Perspec System Verifier product page.
Sign up for Sunday Brunch, the weekly Breakfast Bytes email.