Visibility into Running SoC Silicon? Tell Us More!

As we mentioned in our last few posts regarding the DVCon and SNUG Silicon Valley events, Breker exhibited at both shows with an identical demonstration. We showed our latest product, TrekSoC-Si, generating a test case, downloading it into a commercial SoC (a TI OMAP4430 with dual ARM cores), and running in the actual chip. This demonstrated our ability to support all verification platforms, from ESL and RTL simulation through acceleration, emulation, FPGA prototyping, and silicon.

This demo attracted quite a bit of interest and some good questions at both shows, so we thought we’d devote this blog post to filling in a few of the details. We especially want to stress that we provide exactly the same level of visualization for a multi-threaded, multi-processor test case running deep inside an actual chip as we do when it’s running in simulation or simulation acceleration.

First, here’s a bit more about the demo setup:

The target is a PandaBoard, an open software development platform for the OMAP 4 SoC family from Texas Instruments (TI). This particular board supports the OMAP4430 chip, a very complex SoC with many building blocks and interfaces:

The 4430 PandaBoard provides an SD/MMC card slot, audio in/out, DVI out, HDMI out, WLAN/Bluetooth, USB 2.0 OTG, camera support, and serial UART connectivity. For the purposes of TrekSoC-Si, we were interested in generating multi-threaded C test cases for both ARM processors. We developed a graph-based scenario model that showed the relevant data flows within the SoC and used TrekSoC-Si to generate the desired test cases.

Because we generate C code, our test cases follow exactly the same compile and download process as any other C program, including production software. A host laptop running Windows contains the C compiler and Code Composer Studio, TI’s embedded code development environment. The laptop connects to the PandaBoard via a JTAG interface that is used to download compiled code into memory and communicate with the debugging capabilities of Code Composer Studio.

Once our test cases are compiled and loaded into the SoC memory, they begin running. Amazingly, the same thread display and debugging interface that we provide for simulation is also available for silicon validation. A version of our TrekBox utility runs on the Windows laptop and shows the scheduling of realistic user scenarios across multiple threads and multiple processors. Just as in simulation, this display updates in real time as each scenario executes.

We take advantage of a UART port on the PandaBoard as a communication channel between the running test cases and TrekBox. The test cases send periodic updates via the UART, and these provide the status information necessary to keep the display updated. This display provides an extraordinary level of visibility into our sophisticated generated test cases as they run on the embedded processors deep within the OMAP chip.

Further, the user is able to get the same system coverage metrics from silicon as from simulation. We’ve talked a bit before about system coverage and what it really means, but we haven’t really filled in the details. In a future post we will talk more about system coverage and why it’s so important. We’ll also discuss the ways we report and analyze it for test cases running on all platforms, from virtual prototypes and RTL simulation all the way to actual silicon such as the OMAP chip on the PandaBoard in our demo.

Tom A.

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

Please request our TrekSoC-Si x86 server verification case study at:

www.brekersystems.com/case-study-request/

Tags: Breker, dvcon, EDA, functional verification, graph, OMAP, PandaBoard, scenario model, SNUG, SoC verification, Texas Instruments, TI, TrekSoC-Si, use cases

This entry was posted on Tuesday, March 25th, 2014 at 6:34 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.