| Authors: Matthew Ballance - Mentor, A Siemens BusinessTom Fitzpatrick - Mentor, A Siemens Business Introduction: Electronic design and verification automation have historically been driven by domain-specific languages. The Accellera Portable Stimulus Working Group has released the Portable Test and Stimulus Standard (PSS)[1] to enable capturing of high-level test behavior, including stimulus and coverage goals, to satisfy the requirements of users in multiple verification domains and that can be targeted to verification environments from UVM to tests running on the processors of an SoC. There are also existing Portable Stimulus tools in the industry that implement taking a high-level test specification and targeting that to multiple verification environments. PSS allows the user to create a declarative specification of critical behaviors – called actions – that must be performed by the system-under-test, and the scheduling, resource and data constraints between them. From these specifications, automation may be applied to allow tools to generate multiple randomized scenarios from the original specification. In addition to scheduling, resource and data flow constraints, each leaf-level action in a PSS model also includes templated or procedural interface code – an exec block – that implements the abstract behavior on the desired target platform. This idea of “scenario-level randomization” builds on strategies that UVM users have employed for years and applies similar concepts at the higher level of abstraction necessary to model system-level intent. However, whereas UVM deploys monitors and scoreboards to check functional correctness procedurally, Portable Stimulus poses some challenges for results checking precisely because the PSS model is abstract and declarative, while results checking is often platform-specific. The key to results checking in Portable Stimulus is to understand that different levels of verification and validation environments have different needs when it comes to results checking. In a block-level environment, we might want detailed scoreboarding in addition to an overall per-operation pass/fail. In an SoC environment, we may only need an overall per-operation pass/fail. The original abstract specification may indicate where in the flow results checking should occur, but the abstract nature of the scenario specification itself necessitates that it rely on the target-specific implementation to actually perform the checks. PSS Modeling Basics: Before we can discuss results checking in a PSS model, let us first examine the key elements of a PSS model and how they interact to specify verification intent. As mentioned, a PSS model consists of a set of actions that represent behaviors the system, which includes both the design and the verification environment, must execute. This means that the actions will represent behaviors ultimately executed by some combination of hardware, embedded software and verification components (VIP). Consider a simple UART block under verification as shown in Figure 1. View & Download: Read the entire Results Checking Strategies with Portable Stimulus technical paper. | |