Accellera at DVCon 2025 Updates and Behavioral Coverage

As usual I check in on Accellera activities each year at DVCon. Lu Dai (chair) gave an opening talk at the Accellera lunch, with contributions from other speakers on a few topics. In the afternoon I heard an update on PSS 3.0. What follows is a quick summary with my own musings on behavioral coverage.

Notable non-PSS topics

Karsten Einwich received the Accellera Technical Excellence award for his contributions to SystemC AMS. Interesting to me because an upcoming Innovation blog is based on a paper using SystemC AMS. Pulling AMS verification closer to mainstream verification is a popular theme these days and SystemC AMS adds a complementary system-centric angle.

The Federated Simulation Standard Working Group released a white paper and continues to look for more contributors/participants to help develop ideas. I’m excited to learn more as this evolves, given the ambitious scope of that coupled multi-domain simulation goal, folding in system-wide electronics (aircraft, cars, etc) together with mechanical, fluid dynamics and many other factors that full system OEMs must consider.

The UVM-MS group announced their 1.0 release, aiming to move us closer to a unified verification standard across digital and analog components. This is a very important step, given the increasing contribution analog is making in modern systems, from PLLs and power management, to sensing, to RF.

PSS 3.0

I consider myself fairly technical, though these days primarily in understanding why something is important and the broad strokes of how it is accomplished. I attended the PSS workshop at DVCon knowing quite a bit of the detail would go over my head but in hope that I would pick up a little insight and color. Unfortunately, and perhaps unsurprisingly I wasn’t even a little bit in their target audience. This was very much a hands-on session for practicing PSS users. I can’t blame them. But it did get me thinking more about a cornerstone feature introduced in the 3.0 release – behavioral coverage.

I write quite a bit these days on system verification, as in a big subsystem or SoC, not so much yet on (functional) verification for multi-chiplet systems because published material there is still very thin. However one inescapable fact holds: the bigger the design you need to verify, the more challenging it becomes to develop any sense of verification completeness. Which comes down to coverage, not just “how much testing is enough” but also “what kind of testing is needed”.

Code coverage tells you that you touched every line of code in your RTL. Property checks test for specific state conditions you know you must hit (or not hit). PSS sequences start to probe some paths through the design – initialize an interface, read some data from the input, write that data to the DMA, etc.

But how do you define coverage at the system level? Testing single thread paths through the design is a necessary baseline, but insufficient to account for the concurrency which delivers the main advantage of hardware over software implementations. IO, memory and cache controllers all aim to manage traffic between multiple hosts and multiple targets. As concurrency increases, competition for resources rises adding new complications: latency induced errors, deadlocks, incomplete initialization, prematurely reset flags, memory consistency errors, etc., etc.

Which hints at the kinds of coverage you need to be able to express. Take the memory consistency problem through caching as just one example. You want to check that you have covered all cases where two (or more) threads have successively accessed a cache line through all permutations of read/write and cache flags. If you find this cover has not been exercised, you can bias PSS test generation to make sure it will be exercised. Now extend the same line of thinking to IO subsystem coverage, DDR subsystem coverage, safety and security coverage, anything that spans across the design. A sufficiently expressive way to represent system-level concepts of concurrency-aware coverage is essential to support these needs.

For the more technically able, you can read the detailed spec HERE.