Why Portable Stimulus Must Be Bidirectional

When we first began offering our Trek family of products for what’s now known as portable stimulus, we talked a lot about vertical and horizontal reuse. Vertical reuse means that you can create a scenario model for individual IP blocks and generate test cases to run in their UVM testbenches, then move up to clusters and subsystems. The IP models can simply be plugged together to form a higher-level model from which appropriate higher-level test cases can be generated.

At the full-SoC level, you can generate C test cases that run on your embedded processors. Horizontal reuse is the ability to move from simulation to hardware (acceleration/emulation, FPGA prototypes, and silicon) while generating appropriate tests for these platforms from the same SoC scenario model. We generally described both forms of reuse in a unidirectional flow. However, bidirectionality is very valuable and, we believe, essential for portable stimulus. Let’s cover that topic in today’s blog post.

First of all, let’s remind you of a diagram you have probably seen before:

This diagram is  how we usually explain the concepts behind portable stimulus as well as how our Trek family of products fits into your verification flow. It shows the vertical and horizontal reuse clearly, and we usually walk through the diagram in a presentation by starting at the lower left and working to the upper right. This makes perfect sense, after all, because that’s how most SoC projects proceed. IP blocks are designed and verified, blocks are plugged together into larger clusters and subsystems, processors are added into simulation, and sometimes the chip is also run in emulation or prototypes.

But note that the reuse arrows in this diagram are bidirectional. That’s not just a visual indication that reuse spans the complete vertical and horizontal side of the diagram. These arrows also mean that portable stimulus must work in either direction both vertically and horizontally. Originally, we believed that debug would be the key reason for why bidirectionality is required. We had that in mind from our earliest days, although we didn’t focus on that part of the story as much.

When a bug is found in full-SoC simulation, it’s often useful to be able to reproduce that bug in an individual IP block. Likewise, bugs found in hardware platforms, including silicon in the bring-up lab, should be brought back to simulation for debug. This “backwards” flow is made possible by portable stimulus and our products. Any test case that is generated at any point in the flow can be re-generated for any other target in the flow from the same scenario model.

You may object that some bugs might not be reproducible by this process. That is true; timing behavior in particular differs greatly from simulation to silicon, and so no tool can absolutely guarantee that every bug can be reproduced in a different platform. A bug due to a race condition in silicon is unlikely to show up in RTL simulation, However, running the “same” test case on a different target greatly increases the chances of reproducing the same bug and enabling much better debug capabilities.

So we always planned for, and enabled, bidirectional flow of our automatically generated test cases, but we have been surprised and pleased by how effective this ability has proven for our customers. A paper that we did with Cavium at DVCon this year reported that they first started generating test cases with our tools on chips in the bring-up lab. They then moved back into emulation and simulation both for debug purposes and to experiment with using portable stimulus earlier in their flow.

We have seen this same effect at other customers, where the initial use of our technology is in silicon or emulation, only later in the project moving to simulation. This has given us new ideas on how and where we can help customers, and more insight into the potential for portable stimulus in general. So if you hear of someone claiming to have a portable stimulus solution, be sure to ask them whether they support both vertical and horizontal bidirectional reuse. We’re confident in our answer here at Breker.

Tom A.

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

Tags: acceleration, applications, apps, bidirectional, Breker, cache coherency, coverage, debug, EDA, emulation, FPGA prototyping, functional verification, graph, horizontal reuse, multi-SoC, multi-threaded, multiprocessor, portable stimulus, scenario model, simulation, SoC verification, system coverage, transactional, TrekApp, TrekBox, TrekSoC, TrekSoC-Si, uvm, vertical reuse

This entry was posted on Thursday, August 18th, 2016 at 5:14 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.