Portable Stimulus Layer 2: Test Scheduling

Last week, we continued our  series of posts on the topic of “portable stimulus” as defined by Accellera’s Portable Stimulus Working Group (PSWG) and the standard they are working to define. We should say “we are working to define” since Breker is very much a part of the effort and is providing our many years of experience in this area to develop the best possible industry solution. As a reminder, we at Breker split the definition of a standard for portable stimulus into three parts: defining the tests using abstract primitive operations, scheduling the tests across multiple threads and multiple processors, and randomizing the control flow to verify the full range of realistic use-case scenarios.

Our most recent post dealt with the first layer: defining abstract tests using primitive operations and other elements within a base-class library, with access defined by a simple application programming interface (API). This week we consider the second layer: scheduling of tests and resources. If a verification engineer is writing a directed test for a single-processor SoC using the API calls from the first layer, then little of the second layer may apply. However, as we have discussed before, there is a clear trend of SoC designs moving to multi-processor designs with complex memory and cache subsystems and a rich variety of I/O protocols. These chips require automated test generation and the features provided by the test scheduling layer.

For a start, the user will want to define on which processors the test should run, as well as the number of threads per processor. This level of control is important in building up increasingly complex tests as the design matures throughout the verification schedule, but also in dialing back to simpler tests as part of the debug process. For example, if a four-processor test fails when a particular CPU reads from a specific location, one step in debug might be to re-generate and re-run the test just on the failing processor to see if the read data is still bad. If not, this suggests that the problem may be related to multi-processor issues such as bus contention or cache coherency.

So the API must provide access to the processor and thread definitions. Note that this applies to generated transaction tests as well as C tests. A complex networking chip may have many transactions in progress simultaneously, and these can be managed as threads. The API also must allow the verification team to define shared and exclusive resources, including sections of the registers and memory. For example, one CPU may have exclusive access to one memory page, another CPU may have exclusive access to a second page, and they may both share access to the rest of memory. It is critical to be able to specify the resource-sharing rules to generate proper tests, and it may also be beneficial to be able to generate some “error injection” tests that intentionally violate the rules to see how the system reacts.

As we noted last week, the idea of a base-class library accessed by an API is very familiar to verification teams. They already use library calls to set up their testbenches, configure their registers and memory, run their tests, and check their results. Adding in the first layer of portable stimulus makes their tests both vertically reusable from IP to SoC and horizontally reusable across different platforms. The second layer enables control of scheduling and resource sharing. Next week we’ll fill in some more about the third layer and show how IP blocks can be connected into realistic use cases with randomized options to be sure that all key functionality is verified.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Accellera, API, Breker, C/C++, EDA, Esperanto, functional verification, graph, graph-based, horizontal reuse, IBM, portable stimulus, PSWG, scenario model, simulation, SoC verification, subsystem, SystemVerilog, test generator, UML, Universal Verification Methodology, uvm, vertical reuse, VIP

This entry was posted on Wednesday, May 20th, 2015 at 7:09 pm. 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.