Modern semiconductor verification processes are characterized by complex test methodologies, disconnected verification technologies, and a lack of predictability as to process completion. All of these factors lead to wasted resources, schedule slips, and a question as to whether final products have truly met their original specifications.
1. A typical verification environment is an ineffective and unnecessarily complex mess with disconnected and duplicated tests. (Source: Breker Verification Systems)
What’s required is a single, simple specification format that enables test portability between verification process elements and reuse across many projects. This is the driver behind Portable Stimulus (PS), a standard being defined by the Portable Stimulus Working Group of Accellera Systems Initiatives, a standards organization that supports a mix of user and vendor standards and open interfaces development.
PS establishes a new language and methodology that covers all phases of system-on-chip (SoC) verification . Unlike previous verification languages, such as SystemVerilog and the universal verification methodology (UVM), PS defines high-level verification intent. A verification synthesis engine consumes that description and creates test cases targeting different execution environments, such as simulation, emulation, hardware prototypes, and real silicon.
Generated tests can utilize embedded processors that exist within the SoC design to run parts of the tests. When this is coupled with the ability to coordinate activity on the interfaces, full end-to-end tests can be created that enable a team to define whether design requirements have been met. UVM sequences also can be generated for complex block-level verification problems, previously requiring resource-intensive hand-coding efforts.
The language resolves vertical portability issues that have plagued users of SystemVerilog (SV)/UVM, where lower-level models are difficult to reuse in high-level test environments. An Early Adopter II release is available for review from the Accellera website.
2. Portable Stimulus creates a single, simple specification format that enables test portability between verification process elements and reuse across many projects.
1. Portable Stimulus is just another level of abstraction.
Portable Stimulus is the first complete verification language that exists in the electronics industry. Previous languages concentrated on stimulus, but the PS standard is a complete verification language that encompasses stimulus, checkers, coverage, and takes into account the configurability of the hardware. Scenarios and use cases could be considered abstractions of sequences; the one area where it provides an abstraction boost over SV/UVM.
2. Portable Stimulus is just a hardware-verification language.
While Portable Stimulus can be used to verify hardware, it can directly integrate aspects of the software environment as well. Increasing amounts of functionality are defined in the software that executes on deeply embedded processors. Consequently, it enables a complete SoC verification environment to be constructed. Not all of the necessary functionality may be shipped with the 1.0 release, but this is available in proprietary implementations.
3. Portable Stimulus replaces UVM and SystemVerilog.
Portable Stimulus enhances the existing SV/UVM methodology. Existing solutions target what are currently blocks and subsystems, while PS targets systems and the interaction between hardware and software. At the block level, it’s possible to combine the strengths of both languages—SV/UVM provides transactors and legacy verification intellectual property (VIP), while PS provides a more effective method to generate sequences than hand coding.
4. Portable Stimulus will not support legacy descriptions or files.
Portable Stimulus fully supports legacy SV/UVM descriptions. If sequences have already been defined for a block, they can be called from a PS environment. Existing VIP is fully reusable. Similarly, if legacy C tests exist, they can be used within a PS environment.
5. Portable Stimulus defines visual or graphical representations of a design.
The standard defines two textual languages, neither of which is graphical. Tools are free to provide graphical representations of PS descriptions and may provide graphical input. These aren’t defined by the standard.
6. Portable Stimulus is or is not “graph-based.”
PS is based on graph-based mathematical models, as is almost every description used with the electronic-design-automation (EDA) community, and are ideal for describing operational scenarios. Thus, vendors are able to draw from the vast amount of available research and mature techniques can be utilized in the tools supporting the standard. Graph should not be confused with graphical. The former is a mathematical model. The latter is a visual representation.
7. Portable Stimulus is a way to move stimuli between verification tools.
The name––Portable Stimulus––creates confusion. Portable Stimulus doesn’t define stimulus and the stimulus created by a PS tool isn’t portable. PS is a description of verification intent and, from this description, a verification synthesis tool can generate stimuli suitable for a simulator, an emulator, rapid-prototyping solution, or event actual silicon. It could target other environments, such as formal verification, considered to be the horizontal portability axis.
8. Portable Stimulus doesn’t support C++.
As previously mentioned, PS defines two textual languages. One is a new language created from the ground up and referred to as the Domain Specific Language, or DSL, and a second language based on C++. Both have identical semantics and can be used interchangeably, even within the same module. It’s expected that tool vendors claiming support will support both of these languages, as is the case with Breker.
9. Portable Stimulus doesn’t take into account design intent.
Yes and no. As a verification language, it should be independent of the actual design. It describes what should have been designed. The specification is used to drive the hardware implementation, but the requirements document should drive the PS environment. Verification is the attempt to make sure that the two agree. PS contains one aspect of the hardware implementation in that available resources can be defined, such as the number of CPUs, memory capacity, and DMA channels, and based on these, a PS synthesis tool can generate appropriate tests. As a result, the same verification environment can target multiple design variants.
10. Portable Stimulus is another standard dreamed up by EDA vendors to make more money.
It has been shown that PS generates more efficient tests than existing SV/UVM environments, and those tests can be pre-generated once and used multiple times. This results in more efficient utilization of simulator and emulator resources. Users can decide if they want to reduce the amount of use of either, or continue with the same resources and do additional levels of verification.
11. Portable Stimulus isn’t in use today––we will wait for the standard to be released.
Yes and no. PS hasn’t yet been defined and released. No one has a tool that conforms to the standard. However, tools with this capability are in heavy use across the industry right now, and significant value is being derived from them. Vendors will ensure migration paths exist for the new languages when they become available. An early adopter version of the standard is available today. Although a date for the release of 1.0 has yet to be established, its release is imminent, with the Accellera committee voting to send the 1.0 draft version to the Accellera board for consideration.
