Portable Stimulus: Finding The Killer App

Functional verification vendors have been talking a lot about the Portable Stimulus Standard (PSS), but what is it and why should you care? To put it in stark terms – because it is the first language that supports  verification methodology and because the existing methodology is failing to provide the capabilities required for system-level verification.

All new standards have to become accepted by the industry. The industry talks about crossing the chasm, but what does that mean for a standard? It means some application where the benefits are so obvious that it makes it worth learning a new language and new methodology. For PSS, that is likely to be associated with running system-level tests with CPUs on an emulator. This is the reason why the standard was created and some of the benefits include:

1) PSS can generate longer tests than possible by hand or with UVM.

2) Those tests will be more efficient, saving precious time on the emulator.

3) It will enable a greater number of tests to be created, increasing confidence.

4) It will enable performance tests to be created earlier in the flow.

5) It will enable corner cases to be reached that would be tough for humans to discover.

The language is possibly the least important part of this. This is about defining verification intent captured in a model. From that model, automation can be applied to generate testcases targeted at a number of verification platforms. Think of it as synthesis for verification.

The verification intent model defines paths through a design. This is a complete departure from existing verification methodologies that split stimulus generation, from checking, and from coverage. The verification intent model captures the fundamental actions that a design is supposed to be able to perform, and how to achieve the results.

This is not meant to be a replacement for existing verification functions, although some can be done equally well using the new methodology. It is meant to supplement the system-level verification task, a long, tedious, manual process today. For a modern SoC, this usually means writing code, often in C, to run on the embedded processors of the design. This is not production code and crafting this code to mock up intended functions of the chip can be complex.

We already talked about the potential killer app for the standard, but each vendor and tool has to find their own killer app – the one that makes their tool stand out from the other players. The app that takes them from being used by a small team of verification experts in a company to a tool generally deployed through the entire verification team.

If people look for the killer app today, they may be disappointed. Graph-based verification techniques have not yet crossed the chasm. It is an indispensable tool for a few people in each company who are trying to verify a complete chip from the inside out. It enables them to go from being able to write one or two partial tests to being able to contemplate a comprehensive verification strategy. For this team, PSS is an indispensable tool. However, this task is not conducted by the majority of verification engineers.

Killer apps are usually discovered along the way where they provide large productivity gains compared to an existing methodology, enable more complete verification or provide more efficient usage of resources, such as emulators.  It is likely that existing verification methodologies will respond to the new capabilities provided by PSS over time and usage could grow from system-level down to lower levels of verification. It could also come from IP vendors using PSS to provide more complete verification and documentation of their design.

New methodologies and languages are only adopted where there is real need because there is learning involved. We don’t pretend this is trivial because the concepts are fundamentally different from creating stimulus using SystemVerilog and UVM.

Adoption will take time and a lot of industry education required. Many companies are running pilot projects today while other companies found a need for the underlying technology some time ago. These trailblazing companies enabled Breker and Mentor to refine the concepts of the model and the capabilities required in their tools. This is how the industry evolves – not through a single eureka moment, but by tool vendors working with users to solve problems.

Having said that, Breker is working to help the industry find killer apps and have some candidates in active use. We are doing that by making it easy to insert the technology and to solve specific problems. For example, Breker has defined the complete verification intent model for Arm V8 system integration. These processors appear in many SoCs and the architecture is laden with valuable capability, which requires a degree of verification to ensure correct operation within the SoC.

It can generate tests that revolve around cache behavior, that stress-test memory access, check for correct interrupt operation and more. These verification tasks require large numbers of test sequences and execution is spread across several execution engines. The TrekApp automatically generates many thousands of tests specifically designed to exercise corner case and stress test the design.

Breker has several verification apps and is working on more. Some of these have been directly requested by customers. Even if they do not become the killer apps, they are a useful way in which we can educate the industry, provide a quick start to verification teams and provide an immediate increase in their productivity. Along the way, the real killer app may become clear, but often you only know that in hindsight. It takes collaboration. Together we can do this.

Tags: ARMv8, Breker, Checking, coverage, killer app, Portable Stimulus Standard, PSS, Stimulus, Synthesis, TrekApp

Category: Knowledge Depot

This entry was posted on Thursday, November 29th, 2018 at 11:49 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.