The Breker Trekker
Tom Anderson, VP of Marketing
Tom Anderson is vice president of Marketing for Breker Verification Systems. He previously served as Product Management Group Director for Advanced Verification Solutions at Cadence, Technical Marketing Director in the Verification Group at Synopsys and Vice President of Applications Engineering at … More »
Transactional Design Verification with TrekSoC
August 7th, 2014 by Tom Anderson, VP of Marketing
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.
The truth is out there … sometimes it’s in a blog.