Breakfast Bytes Blogs

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 Fitzpatrick of Siemens EDA
• Matan Vax of Cadence
• Adnan Hamid of Breker Verification Systems
• Hillel Miller of Synopsys

Tom is the vice-chair of the Accellera PSS Working Group.

For some background and history on PSS, see my earlier blog posts:

• A History of PSS
• Intel and PSS...and Simics, a Blast from My Past

Cadence's product that supports PSS is called the Perspec System Verifier, or Perspec among friends.

• A Perspective on Perspec System Verifier
• Perspec Modeling
• MediaTek's Experience with Perspec

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:

• A display controller (Matan Vax)
• Memory and cache examples (Adnan Hamid)
• SoC example (Hillel Miller)

I'll summarize the conclusions of the three examples. First, the display controller:

• PSS supports high-level modeling constructs, resource pools/claims among others
• These constructs naturally capture dependencies across behaviors in the design/test
• Thus, non-trivial flows and schedules can be easily described or randomized
• In contrast, SystemVerilog (and other verification languages) support only constrained randomization of data, hence modeling non-trivial flows/schedules is harder

Memory and cache examples:

• Problem #1: Modeled DDR page address sequences using state variables
• Problem #2: Modeled Coherency State transitions using action inferencing
• Problem #3: Combined problem #1 & #2 using model composition
• Difficult and time consuming to model this in SV or C/C++
• Elegant solutions in PSS

SoC example:

• Showed how to take IP models and simply apply to SOC, using the chaining example.
• Showed how to get fine grained control over interleaving /pipelining stream scenario using schedule together with state flow object.
• For interleaving/pipelined stream example, showed how PSS declarative constructs are used and how it would be very difficult or impossible to do it declaratively in SV.
• Showed how easy it is to combine different types of SOC scenarios, for example combining chaining and interleaving/pipelining stream scenarios.

Tom came back on at the end to wrap up the workshop with a summary:

• Formal IP test space specification. Can be created early in IP lifecycle as documentation of test space
• Formal system scenario documentation. Can be created at SoC architecture definition time
• Quick composition of complex multi-IP test scenarios. Automated handling of state, resource and scheduling dependencies in test.
• Partial test scenario. Create test without deep understanding of complete SoC.
• Test generation time and runtime coverage reports. Coverage for power state transitions, functional modes etc.
• Tests are portable. From IP (UVM/SystemC) to embedded processor on SoC to post-silicon

Learn More

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.

.