Transactional Design Verification with TrekSoC

In our last blog post, we worked our way up the conclusion that our TrekSoC product can be used to verify designs that do not contain embedded processors. As we noted, there is not a widely accepted industry term for such devices. For the moment, let’s call them “transactional designs” since the majority of them take transactions in at one end and generate transactions at the other end, sometimes for two very different protocols, and are often bidirectional in nature.

The technological argument is simple. Most SoCs also have I/O ports, both standard buses and proprietary protocols, and TrekSoC must be able to talk to them, coordinate among them, and synchronize their transactions with generated C code running in the embedded processors. A purely transactional chip and testbench form a subset of the challenge for which TrekSoC is designed, so it’s not surprising that we can help. Today’s post fills in some more details.

Our last post also discussed how TrekSoC must support reuse from IP blocks through subsystems to complete chips. We included the following diagram to show how this works:

Note that, in this diagram, the IP block being verified standalone is one of the blocks attached to the bus fabric. Thus, just like the middle “headless” subsystem, the UVM verification component (UVC) for the processor bus is a stand-in for the processors themselves This bus UVC must provide the same sort of operations on the IP blocks as does the TrekSoC-generated C code running in full-chip simulation. These include configuring the IP block, setting it up for DMA operations if it is DMA-capable, and controlling the flow of transactions to or from the interface UVC.

Not all IP blocks in an SoC connect directly to the bus fabric and have a CPU-programmable register interface. Some IP blocks may have very simple interfaces to the adjoining blocks, or at most purely transactional interfaces:

TrekSoC has no problem handing verification for this type of IP block as well. As usual, it provides UVM transactions to the two interface UVCs and coordinates their activity with the TrekBox runtime element. Graph coverage is calculated on the IP block’s scenario model, including unreachability analysis and automatic coverage closure as requested by the verification team. This type of graph may be composed with those of other blocks to form higher-level scenario models.

Here’s a new and interesting question: what if it is possible for multiple transactions to be active within this block at the same time? We know that TrekSoC can generate multi-threaded C code for SoC designs that support multiple scenarios in parallel. This same level of support must work on headless systems and all IP blocks attached to the fabric. However, multiple threads are also supported on transactional interfaces and purely transactional designs,  such as the header editor block.

So we’ve now established that TrekSoC can handle purely transactional designs, and that these can be combined together into arbitrarily larger blocks. So we’ve followed a different path than our last blog post but ended up at the same point: in addition to SoCs, Breker knows how to verify large, complex chips that do not contain embedded processors. We’ll continue filling in the details in our next blog post, focusing on chips such as routers, switches, bridges, and modems.

Tom A.

Tags: Breker, coverage, EDA, functional verification, graph, portable stimulus, reuse, scenario model, scoreboard, sequencer, SoC verification, transactional, TrekSoC, UVC, uvm

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