Expanding Our Scope to Multi-SoC System Verification

For more than four years now, Breker has branded itself as “The SoC Verification Company” and many people acknowledge our expertise in this domain. As we have discussed before on The Breker Trekker, our initial products focused on generating purely transactional tests for a simulation testbench, usually compliant with the Accellera Universal Verification Methodology (UVM) standard. When we extended our products to generate C code that runs on the embedded processors found within SoCs, we delivered on our “tagline” promise.

Since our early focus on simulating an SoC, we have expanded our technology and our product line to generate C test cases that run on embedded processors in emulation, FPGA prototypes, and actual silicon in the bring-up lab. In talking about what we do, we struggle to choose between “SoC” and “system” since for many of our customers the terms are synonymous. But we also have users verifying multi-SoC systems, and today we’d like to address that topic.

The very definition of “SoC” is “system on a chip” which means that a system-level design previously implemented with a multi-chip solution now fits into a single device. But this term does not necessarily imply that a single SoC is the complete system. In fact, many of our customers build boards or multi-board systems containing dozens or even hundreds of SoCs. All the advantages of using graph-based scenario models apply equally well to these designs as to a single SoC.

This is an important point: the divisions between blocks, chips, boards, and systems are largely immaterial for Breker’s technology. We need to know the number of processors, some details about the architecture of the design, and the I/O ports if you want us to generate testbench transactions that synchronize with the C test cases. The process works the same whether those processors are all in one SoC or distributed across multiple chips or boards.

However, our experience is that few customers run RTL simulation at the board or multi-board level. One challenge is the difficulty of getting reliable models for purchased components. Another is the sheer size of a full system; many users find it hard enough to simulate a complete SoC let alone a larger configuration. Finally, even if a simulator has the capacity to load the model, the speed is likely to be too slow to be practical.

Two important shifts are happening to change this situation. Due to the limitations of simulation, some projects are moving to hardware platforms such as emulators and FPGA prototypes to verify individual SoCs. In a few cases, usually due to the cost of such platforms, some aspects of SoC verification don’t happen until the silicon is available. As previously noted, we can generate test cases for whatever platforms the users choose.

The second shift is toward combinations of a few SoCs that interact very closely and therefore benefit from being verified together. Simulation is impractical due to capacity and speed issues. However, our TrekSoC-Si product can automatically generate test cases for a multi-SoC configuration on a hardware platform just as easily as for a single SoC. We are now seeing users operate in exactly this way, showing on real projects that our solution scales beyond the SoC level.

We strongly encourage you to attend the Design and Verification Conference (DVCon) in San Jose in a few weeks. This is a must-see event for anyone involved in digital verification or validation. We specifically encourage you to hear talk 1.3 on Tuesday morning. We’ll be discussing verifying cache coherency in a customer’s large SoC, but also presenting some recent results in which we are generating test cases for a multi-SoC configuration with well over 100 cores.

Yes, you read that correctly. TrekSoC-Si has automatically generated many test cases with more than 100 C files, all fully multi-threaded and coordinated, and the customer has run them in a multi-SoC configuration on real silicon in the bring-up lab. It’s a great demonstration of the power and extensibility of the Breker approach. Of course, we’ll also have a booth at DVCon and we invite you to stop by to visit. See you there!

Tom A.

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

Tags: application, Breker, bring-up lab, cache coherency, dvcon, emulation, FPGA, functional verification, graph, graph-based, multi-SoC, node coverage, path coverage, portable stimulus, prototyping, PSWG, realistic use case, scenario model, simulation, SoC validation, SoC verification, system-on-chip, test case generator, test cases, TrekSoC-Si, Universal Verification Methodology, use-case coverage, uvm

This entry was posted on Wednesday, February 3rd, 2016 at 6:03 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.