Developing Tests in Reverse with Portable Stimulus

Whether developing tests for software or hardware, test development seems to follow a pretty predictable process: learn about the thing to be tested, catalog its critical operational modes and features, then write tests to exercise those features. There’s nothing particularly wrong with this model, but it does limit test reuse because the created tests are targeted at the design being tested.

Reversing the Process

What if we reversed the process and started by capturing our test intent for an area of functionality, then moved on to specialize that test intent with design details? For one thing, our test intent would be fairly high-level. For another, it would be reusable across any design where we needed to test the same type of functionality.

Now, it might seem like the cases might be few and far between where we could reverse the test-development process. All designs are unique, right? However, your garden-variety SoC provides one interesting example of an area where this approach can be applied: the memory subsystem.

We need to verify the memory subsystem of every SoC, and it seems a shame to start from scratch (or very nearly) every time.

Portable Stimulus to the Rescue

Accellera Portable Stimulus brings some very powerful features to the table in raising the level of abstraction at which test intent can be captured. Because the description is declarative, a PSS description is very easy to reuse, shape, and customize without changing the fundamental description. Type extension also enables design-specific details to be “layered in” to an existing description without changing it.

When approaching our memory subsystem verification and validation task with PSS, we can start by modeling the basic aspects of sending traffic across the system: data starts at one place, then is moved a number of times by initiators in the system, and we want to ensure all initiators send data to all memory regions. Just like the diagram figure indicates, we can model this generic test intent without knowing anything about the actual initiators or memory regions in our system!

Read All About it!

Of course, this small example just gives a peek at how we implement creating test intent in reverse. For all the details, check out my article titled Getting Generic with Test Intent: Separating Test Intent from Design Details with Portable Stimulus in the latest issue of Verification Horizons.