Better Virtual Sequences with Portable Stimulus

If you’ve used UVM for verification, you’ve almost certainly worked with virtual sequences. Once our needs for verification stimulus go beyond exercising a single interface, or even beyond exercising a single interface with a defined sequence of operations, we need a virtual sequence.

Because virtual sequences need to deal with test scenarios – multi-step behaviors – they are written using directed test or directed-random test techniques.

How Does Portable Stimulus Help?

Think about a UVM sequence to test a DMA engine, like that shown below.

Describing simple test sequences is pretty easy to do with a simple UVM sequence. However, when we need to run scenarios – for example, multiple transfers in parallel – our UVM code gets a bit more complex. We can certainly implement UVM sequences that test these types of scenarios, but the directed-random sequence that we would write to manage these conflicts gets complicated in a hurry, and isn’t very flexible or customizable.

With PSS, we provide a bit more information about the relationships between the elements of our scenarios. For example, below are graphical depictions of three operations (PSS actions) that we might perform with our DMA engine, along with the data required for each to execute, and the data produced by that operation.

This small amount of additional modeling makes our PSS scenario more transparent, and allows us to customize the rules under which our scenario operates instead of modifying the implementation of our scenario.

Consider a typical directed-random sequence to run parallel transfers on different channels of a DMA engine:

This is perfectly functional, and uses a queue to ensure that the parallel transfers are on different channels, but how would we constrain this from outside to force the transfer sizes to be different? With UVM, we’d probably have to rewrite the sequence because we can’t place constraints on procedural code.

With PSS, we can place constraints on the behavior (the activity) from outside the action. In the code below, parallel_xfer_a is the PSS action that implements our parallel transfer scenario. Creating a specialized scenario to ensure that the transfer sizes are different on the two parallel transfers is as simple as the code shown below.

More reusable, more concise, more powerful!

Learn More

Like what you see? Building a Better Virtual sequence with Portable Stimulus, my most recent article for Verification Horizons, provides a detailed explanation of how Portable Stimulus simplifies and enhances the modeling process for UVM virtual sequences. Portable Stimulus enables the test intent that drives your UVM environment via virtual sequences to be more flexible, customizable, and reusable – all without requiring any more code (and quite possible less) than you’re currently writing!