Accellera và PSS 3.0 tại #61DAC
Accellera invited me to attend their #61DAC panel discussion about the new Portable Stimulus Standard (PSS) v3.0, and the formal press release was also just announced. The big idea with PSS is to enable seamless reuse of stimulus across simulation, emulation and post-silicon debug and prototyping.
Tom Fitzpatrick from Siemens EDA was the panel moderator, and he shared that a leading challenge was creating sufficient tests to verify the design. Debug time is the bottleneck. UVM is good for modular, reusable verification environments, but only a small group of people understand how to verify and bring up a chip. UVM isn’t great for creating test content, as scoreboard checkers are manual, and UVM isn’t scalable for concurrency, resources and memory management. So having PSS + UVM provides the required abstraction, and PSS provides schedule for a UVM environment, with UVM providing structural features and PSS providing features tailored for test scenario creation. PSS really complements UVM, not replacing it.
Major new features
- Added “behavioral coverage” clause / Added “Formal semantics of behavioral coverage” annex
- Coverage performs a critical role in assessing the quality of tests. PSS has supported data coverage (think SystemVerilog covergroups) since its first release, but being able to collect coverage on key sequences of behavior is critical for system-level verification, where PSS focuses. You can think of PSS behavior coverage as “SystemVerilog assertions (SVA) for the system level”. It allows users to capture key sequences of behavior and key behaviors that must occur concurrently, and to collect coverage data proving that these key behaviors were executed.
Minor new feature or incremental changes to existing features
- Added address space group
- PSS models memory management as a first-class language feature that allows users to characterize different regions of memory (eg ddr, sram, flash, read-only, read-write, etc) and specify test requirements for memory. When combining PSS models from different sources that access the same overall address space, it can happen that the different model creators characterized memory in different ways. Address-space groups improve reuse by allowing models that characterize memory differently to work together.
- Added support for “sub-string operator” and string methods
- PSS has had support for a string datatype since its initial release. The new operators and methods provide new ways for users to manipulate the values stored in strings.
- Added support to allow collection of reference types
- This enables more-complex PSS models to be created.
- Added support for comments in template blocks
- PSS supports a code-generation feature that is used for targets that require very specific control over the test structure (eg PERL scripts or specific assembly-language tests). This enhancement allows adding comments into the ‘template’ blocks used to generate the output code. This helps users as the develop PSS models by allowing them to temporarily disable portions of a template with less effort.
- Added support for yielding control with cooperative multitasking
- Test code running on a single core runs cooperatively. The yield statement allows the user to explicitly code in points at which other concurrently-running test code should be allowed to execute – for example, while polling a register to detect when an operation is complete.
- Added PSS-SystemVerilog mapping for PSS lists
- PSS defines interoperability with SystemVerilog, C, and C++. This enhancement allows PSS list variables to be passed to SystemVerilog, enabling more-complex data to be passed.
Clarifications, etc
- Added support to allow platform qualifiers on function prototype declarations
- Clarified static const semantics
Panel Discussion
Panel members were:
- Dave Kelf – Brekker
- Sergey Khaikin – Cadence
- Hillel Miller – Synopsys
- Freddy Nunez – Agnisys
- Santosh Kumar – Qualcomm
Q&A
Q: What is your favorite PSS feature?
Sergey: The resource allocation feature, because I can create a correct by construction test case for DMA channels as an example.
Hillel: State objects with schedule. Sequences are correct by constraint.
Santosh: Inferencing of actions.
Freddy: One standard for multiple platforms.
Dave: Reusability.
Q: What are the challenges to learn another language like PSS?
Santosh: Folks from SV know about constraints, newbies learn the declarative nature, so the ramp up time is not too high with PSS, so there’s no going back.
Sergey: We’re teaching PSS in classes, and it’s a concise language, so there’s a mindset change from procedural to declarative, so we let the tool do the magic work.
Hillel: Freshers like to learn the PSS in just a week or two.
Dave: Mindset is the real barrier. Following a path to learn the methodology first, then language second. Expert users or services company are the first to adopt PSS. There’s a small adoption from those who create VIP models. PSS will grow just like Formal verification grew. VIP with PSS and C behind it are growing.
Q: Why isn’t everyone using PSS yet?
Dave: It’s a new language, system VIP is the killer app. More libraries are added each year.
Hillel: The PSS standard enables more validation and verification.
Q: UVM enabled reusable test environments, what about a PSS methodology library for VIP?
Dave: Absolutely. How to get new people to adopt it are showing the ease of use, so it’s an education issue.
Santosh: We need a standard methodology around using the standard. Applying PSS to verification, vs the UVM learning curve.
Freddy: PSS can do so much, but many don’t know how to first adopt it efficiently.
Q: How about formal vs stimulus free approaches? What about gen AI to create more stimulus?
Dave: The declarative approach in PSS is similar to the formal approach for verification.
Hillel: PSS is better than Excel and Word documents for an executable spec.
Santosh: Scenario specification is like an executable spec, so use the PSS language on how to program IPs.
Dave: PSS is really an executable spec standard.
Q: PSS usage is too low, who is using it today?
Sergey: There’s already a wide range of PSS users, and most of the verification pain is coming from multi-core embedded designers where they have a UVM environment with more than a dozen agents and too many virtual sequences.
Dave: I see PSS being used for large multi-core SoCs, verifying coherency and power domain testing, really, across the board use, even DSP applications.
Hillel: Wherever verification managers have pain in their present methodology.
Q: Why join the PSS committee?
Dave: It’s a great learning experience about verification and you get to talk with so many different users.
Sergey: We’ve been using this for many years and are new to the committee, and I see that both vendors and customers that are working on real challenges. New volunteers bring I new requirements.
Hillel: Constraint solvers are improving and need to be more scalable.
Freddy: We always need new eyes on the language standard for feedback.
Santosh: More people will just strengthen the standard features. Start out with questions, then build to requesting new features.
Q: When does PSS get into IEEE standards?
Tom: PSS 3.0 is coming out in about August or so. Likely 3.1 is required before going to IEEE standards in a year or two.
Q: Will IP vendors provide PSS models and IP XACT models?
Tom: Yes, that’s ideal. IP vendors should provide the models.
Freddy: PSS will complement IP XACT, not compete with it.
Conclusion
The tone at this #61DAC panel was very upbeat and forward looking. Verification engineers should consider adopting PSS 3.0 in their methodologies along with UVM. The Accellera committee has been accepting new feature requests in the PSS specification and forging improvements along the way.
Read the press release for PSS 3.0 from August 29th.
Related Blogs
Share this post via:
