Performance Verification: Bringing Your SoC to Its Knees

For those unfamiliar with the expression in the title, bringing someone (or something) to its knees means making it submissive. It’s a metaphor possibly derived from the act of hitting someone so hard that his knees buckle and he falls to a kneeling position. Why such a nasty term to start this post? Because when you want to verify the performance of your SoC you want to stress every aspect of it. You want to be mean to it. You want to bring it to its knees.

The most common way to do this is to run production software (operating systems plus applications) on a virtual prototype, a high-level system model created by architects before RTL implementation begins. This is not easy; it takes effort to set up workloads that will stress the design and often production software is not ready at this early stage of the SoC project. Further, this verifies only the high-level model, but RTL simulates too slowly to replicate the same tests, or often to boot the operating system at all.

Hardware platforms such as emulators and FPGA prototypes may be capable of running production software, but these are available well along in the project. At that stage it’s too late to uncover performance-related bugs that could ripple changes all the way back to the SoC architecture. What’s needed is a set of tests that can run on the full RTL design in simulation while saturating processor buses, memory interfaces, cache coherency logic, and I/O channels.

There is no hope of writing such tests by hand; humans have limited ability to think in parallel. Writing multi-threaded C code for every SoC processor and having the programs all work together to access different memory blocks and I/O channels in parallel would be very difficult. Any tests that sent or received data off-chip would also have to be carefully coordinated with testbench activity. The Universal Verification Methodology (UVM) doesn’t help because it deals only with the testbench, not code running on the processors.

The only viable answer is a mechanism for automatically generating multi-threaded, multi-processor test cases that run efficiently enough in simulation to bring your SoC to its knees. Breker’s TrekSoC is fully capable of doing this from graph-based scenario models of the SoC. We have referenced the following screen shot before since it does an excellent job of showing how tightly we can interleave multiple threads, all representing realistic user scenarios, across multiple processors.

We have mostly talked about such testcases in the context of speeding up verification and finding corner-case bugs related to IP block interactions. But we have found on multiple customer projects that the high level of activity we generate is ideal for measuring performance (throughput, bandwidth, latency, etc.) and identifying any bottlenecks.

Because our generated tests run on bare metal, with no operating system required, they simulate much faster than production software. We also run very well on virtual prototypes, offering system architects an easier way to assess performance in the early phases of the SoC project. Because graph-based scenario models are ideal for reusable and portable verification, TrekSoC-Si can generate similar test cases tuned for acceleration, emulation, FPGA prototypes, or fabricated silicon.

Verifying the performance of a complete SoC requires a reasonably complete scenario model for the chip. However, there is considerable value in measuring just the activity among the processors, caches, and memories. Our Coherency TrekApp is all you need to provide this level of exercise for your SoC. Since the graph is pre-generated, all you need to do is provide some system configuration information and push a button.

With Breker, you can enter into a much easier and more effective era of SoC performance verification. You can start with our app to verify cache coherency while measuring your processor and memory subsystem performance. You can extend the coherency graph to cover other coherent agents and IP blocks in your design, and complete your system-level verification of both functionality and performance. If this sounds interesting, please contact us.

Tom A.

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

Tags: acceleration, applications, apps, Breker, coverage, EDA, emulation, FPGA prototyping, functional verification, graph, performance, portable stimulus, reuse, scenario model, SoC verification, transactional, TrekSoC, TrekSoC-Si, TrekUVM, UVC, uvm

This entry was posted on Wednesday, October 22nd, 2014 at 3:56 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.