Portable Test – Portable Intent, Portable Realization, or Both?

The Accellera Portable Stimulus Working Group (PSWG) has been hard at work defining a language specification for capturing portable test and stimulus. But, what does a portable stimulus specification really make portable?

When it comes to test portability, there are two key things to consider: test intent and test realization. Test intent is all about the big-picture view of what is being tested. Test realization is the details of how it is verified.
Let’s say we’re testing a DMA controller. Our test intent would specify test scenarios that we want to exercise on the DMA controller – things like running transfers of various sizes, and running parallel transfers on different channels with the same and different priorities. Notice that we haven’t said anything about how we will exercise the DMA controller. That’s where our test realization comes into play. In a UVM environment, our test realization might use the UVM register model to access the DMA engine’s registers and use a UVM agent to intercept interrupts. In a bare-metal embedded software environment, we would use C code statements to access the DMA engine’s registers and an interrupt handler to react to interrupts.

Accellera’s Portable Stimulus standard really focuses on making test intent portable, which is a very useful thing. This allows us to apply the same highly-automated test scenarios in our IP-level environment and in our SoC environment. All we have to do is provide the appropriate test realization layer.
In many cases, this scenario is ideal since it allows the same test intent to be reused across very different environments and very different test realization layers. In some cases, though, reusing test realization is also very helpful.

What if you need Portable Realization?

Hardware IP increasingly has software content and requiring tight interaction with software. Developing this firmware early and reusing it across the verification flow both boosts productivity and helps to find hardware/software interface bugs early while they’re easiest to debug and fix. In this situation, needing to re-create the test realization layer for each environment isn’t just wasteful, but doesn’t allows us to test what we need to test.

The UEX API was developed by Mentor to address precisely this use case. UEX is an acronym for micro (U) executor (EX), and provides APIs commonly used by firmware – memory-management and access, interrupt handling, and threading. Multiple environment-specific implementations of the API allow the same test-realization firmware to be run in UVM environments, bare-metal embedded software, and other environments.

When used together, Accellera PSS provides automated test scenarios created by portable test intent, while UEX allows portable and reuseable test realization. Like many pieces of verification infrastructure, such as UVM, UEX is available on GitHub under the Apache 2.0 license.

DVCon 2018

Will you be attending DVCon February 26th to March 1st? If so, there will be a lot to see about portable test and stimulus! Come to Accellera’s Portable Stimulus Tutorial on Monday to learn more about how the emerging standard is applied. On Tuesday morning, come see how portable stimulus techniques are already being applied at the inaugural DVCon Portable Stimulus Applications session. Just after that, come visit my poster paper Managing Hw/Sw Tests from IP to SoC, which is about using portable stimulus and the UEX API together. And, come find me at the Mentor booth all week if you’d like to talk about portable stimulus or Mentor’s inFact portable stimulus product, or verification techniques in general.