PSS is the Accellera Portable Stimulus Standard. Or I should say proposed standard, since it isn't finalized yet. At CDNLive India, Prabhat Gupta of AMD presented First Encounter with Emerging Portable Stimulus Methodology. Of course, since the standard isn't final yet, there are moving parts in all of this, but AMD decided to try it all out on a pilot project involving the Ryzen muliti-core, multi-thread CPU. Since most people in the audience probably knew little about PSS, Prabhat gave an overview of PSS and of the Perspec System Verifier, Cadence's system-level verification tool that implements all (or most?) of the proposed PSS standard. This is not so much due to Cadence's engineering team doing a blazingly fast implementation, as that quite a bit of the standard is based on Perspec, which predates it (the other main EDA contributors are Mentor and Breker). I won't repeat his introduction here. If you are not already up to speed on PSS and Perspec, then see my earlier posts on the topic: Portable Stimulus Standard A Perspective on Perspec System Verifier Perspec Modeling Mediatek's Experience with Perspec How AMD Used Perspec AMD was using Perspec to run system-level tests on Ryzen, a multicore CPU. The high-level goals were to create infrastructure to run Perspec tests on: SimNow (a fast platform model) Ryzen silicon Emulation model on a Palladium platform What they hoped to find was: Better validation of firmware and diagnostics before they got silicon back from the fab, as early in the design cycle as possible Be able to run tests on bare-metal (with no operating system), which doesn't waste a lot of emulation time handling the operating system Better SoC tests, handling complex interactions and better testing of power management (turning cores on and off, in particular) A sort of cultural aim was also to bring the pre-silicon and post-silicon teams closer, since they would be using the same PSS infrastructure to give canonical representation of stimulus. Plus, of course, they hoped to improve time to market. There were four teams collaborating: the CPU diagnostic team, the CPU core IP team, the BIOS team, and the emulation methodology group. Steps to the First Perspec Test The Perspec model of Ryzen was configured from a spreadsheet that configured the number of threads, the cacheline size, the sizes of the L1, L2, and L3 caches, cache associativity, and more. A Perspec test loader was created that ran on the UEFI BIOS. This allowed one or more precompiled Perpec test binaries to be loaded and started on all available threads (see the diagram below). Generate simple coherency tests, using a portable coherency action library from Perspec. Perspec debugging APIs (printf, etc.). The Test Scenario Run actions concurrently on two threads of a given core, with each thread doing streaming store and cacheable loads. One thread's streaming store addresses are the same as the other thread's cacheable loads (so they potentially step on each other if there are bugs). Do this simultaneously on all cores, with some runtime variations. Then vary the parameters slightly so that Perspec generates hundreds of tests. Prahbat showed a lot of the actual code, but that seems a bit too low level for a general interest post like this. The presentation should be available soon on the Cadence website (under CDNLive India). Strengths of Perspec and PSS Model creation: It took one day to create the basic model to start creating scenarios New language makes it easy to create simple actions, but need training to create complex compound actions (but the Perpec library is a great help here) Complex scenarios can be composed from simple actions using SLN (system level notation) The GUI is useful for exploring scenarios (but there is a command line for people who like command lines) Perspec can generate all possible tests to fulfill a partially specified scenario, which is a big boost to productivity Portability: Generated C tests are easy to target to SimNow, emulation, and actual silicon Great for SoC-level test scenario creation Challenges with Perpec and PSS Fine-grained timing control of threads can be difficult, which was required for some corner-case scenarios Better compile time and runtime randomization is needed to stop runtime actions being more deterministic than in the real world Expertise is needed for modeling complex tokens or write procedural SLN code, and procedural SLN code may be needed to reproduce some corner-case bugs Takeaway Partial scenario specification composed of simpler actions is a good way to generate stimulus. Perspec interleaves things randomly to create better stimulus. Complex traffic pattern with power state transition scenarios is easier to create using PSS Time and runtime coverage reports are great for diagnostic tasks Getting started with CPU-based tests is fast More than 90% of actions should just need simple declarative SLN code, but expertise is needed to model complex memory tokens and how they map onto the memory Perspec likes to work with static addresses generated at code generation time, which can be a challenge in a bare-metal environment without full address in place Final conclusion: Portable stimulus methodology is great for creating complex system-level stimulus that would be really hard to create by hand. Automate. Automate. Automate. Sign up for Sunday Brunch, the weekly Breakfast Bytes email![]()
↧