Open side-bar Menu
 The Breker Trekker
Tom Anderson, VP of Marketing
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 »

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

 
January 20th, 2015 by Tom Anderson, VP of Marketing

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.

TrekSoC-Si DS DLx86 CS ReqContact Req

Related posts:

Tags: , , , , , , , , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy