Every aspiring and growing verification engineer might be searching for the answer to the question ‘What is PSS?’, as it’s an interesting concept that will transform the manual or semi-automated verification process into completely automated and thereby the change of their job function and role. So I would like to throw some light and help them to understand how their future would be with PSS. Let me start with the definition of Accelera that is working on standardizing the PSS.
Accelera – Definition:
The Portable Test and Stimulus Standard defines a specification for creating a single representation of stimulus and test scenarios, usable by a variety of users across different levels of integration under different configurations, enabling the generation of different implementations of a scenario that run on a variety of execution platforms, including, but not necessarily limited to, simulation, emulation, FPGA prototyping, and post-Silicon. With this standard, users can specify a set of behaviors once, from which multiple implementations may be derived. Ref: https://www.accellera.org/downloads/standards/portable-stimulus
Let me explain what it means. PSS is a verification language that uses a higher level of abstraction [Like graphical representation in terms of states] which is suitable to define the verification intent of the design [DUV – Design Under Verification].
Using PSS one can model the verification intent of design at a higher level of abstraction independent of the language [HDL/C/SystemVerilog/UVM, etc.] and EDA platform [Simulation/Emulation/FPGA prototyping, etc.].
From the DUV specification, verification engineers can directly define and create the PSS model [Verification Plan in terms of test scenarios]. Based on the requirement, they could generate the testbenches/verification environment in any language directly from the PSS model using the EDA tool [Test/VE Generator] and do the verification on any platform, simulation/emulation.
PSS is evolving and it will become a standard verification language in the future, like how SystemVerilog has grown as an IEEE standard language. In parallel EDA vendors are also working on providing the EDA tool[[Test/VE Generator] that can generate the testbenches/verification environment in any language [C/SV/UVM] directly from the PSS model, based on our choice of the platform like simulation/emulation.
Why do we need PSS?
We use different kinds of verification methodologies to verify different kinds of designs like IPs, Chips, and SoCs. Usually, we prefer SV based random testcases[UVM] to verify the IPs and C based directed testcases to verify the Chips and SoCs. Also, we manage the IP level regression testing on a simulator, but we may prefer emulation/FPGA prototyping to accelerate the SoC verification process. As we need to use different languages like SystemVerilog or Verilog or C or Python to create the verification environment at different levels like IPs, Sub-Systems, Chips, and SoCs, we may not be able to reuse the IP level testcases/verification environments at the SoC level. So, usually, we rewrite/modify the IP level testcases to use them at the SoC level. This is completely a manual process and it’s more time-consuming.
Refer my blog: IP Vs SoC Verification
In order to automate the stimulus/testcase generation in different languages for different platforms[Simulation/Emulation] using the EDA tool [Test/VE Generator] and accelerate the verification process reusing the testcases at every level, we need PSS.
Using PSS language we can define the verification intent of any design IP/Chip/SoC and generate the verification environment in any language [testcases for simulation/emulation/FPGA prototyping] using the EDA tool.
For example, we can define the stimulus in PSS and verify the IP on the simulator, generating UVM testcases. To verify the same IP using a formal verification tool, we could also generate the SystemVerilog assertions and scripts using the same PSS model.
Later on, we can use the same IP – PSS model and generate C testcases to verify the SoC that uses this IP on the emulator. If we are planning to use FPGA prototyping to verify the SoC, still we can generate the IP testcases in some other suitable language from the PSS model.
This way, the IP level C testcases can be easily reused along with the other SoC level C testcases which will run on emulation/FPGA prototyping. So PSS enables us to automate the stimulus generation and reuse the same stimulus[PSS model] at different levels on different platforms.
Conclusion:
PSS – Portable Test and Stimulus Standard is evolving and Accelera is working on standardizing it with the help of EDA and Semiconductor Industry experts. In parallel, EDA vendors are also working on the EDA tools that can automate the stimulus generation using PSS. In the future, verification engineers will work with design architects and engineers and drive the complete design and verification process. Our job will be mainly defining the verification intent and signing-off the verification through coverage closure, debugging the simulation failures. Let the EDA vendors automate the test generation. Hope the DV engineers community accepts and adopts PSS like the way they adapted and evolved along with SystemVerilog & UVM.
