What to Run on Day One in the Bring-Up Lab

Last week’s blog post raised the question of what you should run when you first map your system-on-chip (SoC) design into an emulation platform. We pointed out that trying to boot an operating system and applications immediately was a challenge because these are complex pieces of production software not designed to find lingering hardware design errors or to debug such errors easily even if detected. On many projects, the production software isn’t even available early enough to be used for design verification.

We strongly recommended running the multi-threaded, multi-processor, self-verifying C test cases generated by our Trek family of products. These “bare metal” test cases run on your SoC’s embedded processors at every stage of the project. TreSoC-Si specifically generates test cases tuned for emulation and FPGA prototype platforms. But what should you run when your fabricated chip first arrives back from the foundry? The answer is the same. TrekSoC-Si also generates test cases for silicon, ideal for use in your bring-up lab. Let’s explore this idea a bit more.

When the first instance of your chip arrives, it’s tempting to immediately solder it onto whatever production board you will use in your final system, load up production software, and start running. In practice, this is a big step that rarely works on Day One of bring-up. Expecting the chip, the board, the software, and the lab bench set-up to all work together instantly and flawlessly is unrealistic. Most SoC projects break the bring-up process into multiple steps, starting by testing the chip in a dedicated test fixture of some kind.

Typically this fixture is attached to a host machine that controls the SoC’s operation, downloads software to be run in the chip, and provides some amount of debug capability. Your production board can be used rather than a test fixture as long as it provides the bidirectional access needed to support the host system. The key point is that your bring-up lab must provide a degree of SoC control and observation beyond what is needed in your final product. Without such capabilities, debug of any running software is extremely difficult.

Many SoC projects first download simple hand-written C tests that verify specific parts of the chip. Humans are not good at thinking in parallel, so these tests do not run in coordinated fashion on multiple processors. They will probably wring out most issues with your host system, code download process, and test fixture. They will not do a good job of verifying the SoC itself. If you followed last week’s advice, you will have already run far more sophisticated test cases during emulation, so uncovering new design bugs in the lab with simple tests is unlikely.

In contrast, running the test cases generated by TrekSoC-Si will truly stress your SoC design. Parallel threads will hop from processor to processor, exercising every cache, interconnect, and memory in your chip. If your bench set-up provides access to send data into the chip and retrieve results, then the test cases we generate will also verify your I/O interfaces, fully coordinated with the code running on your embedded processors. As in emulation, finding and fixing lingering hardware bugs this way results in faster bring-up of the production software.

At this point, you may be asking why our test cases would find any new bugs in the lab not already found by running in emulation. Note that our Trek family generates test cases optimized for the designated target platform. You use the same graph-based scenario models as input, but you generally want different test cases for different targets. Since your actual chip runs much faster than emulation, often 1000x or more, our silicon test cases are designed to run a massive number of cycles with minimal code downloads.

The sheer number of test cases than you can run in your lab provides even more stress on the design and exercises even more of the SoC’s capabilities. We also detect basic issues with your download and lab set-up, easier and faster than hand-written tests since our test cases are self-checking with better debug capabilities. We even provide coverage metrics from test cases running in silicon, a unique feature. For all these reasons, we recommend that our test cases be run on Day One when your chip arrives from the foundry. You’ll be glad that you did.

Tom A.

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

Tags: acceleration, Breker, bring-up lab, EDA, emulation, functional verification, graph, portable stimulus, scenario model, simulation, SoC verification, test generation, TrekApp, TrekSoC-Si, use cases

This entry was posted on Tuesday, January 20th, 2015 at 3:32 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.