Stitch and ship will sink your chip every time

2/7/2013 1:29 PM EST

Question: When should a chip developer think like a systems integrator? Answer: Always. If not, a “stitch and ship” mentality is guaranteed to sink any consumer electronics device or other electronic product and, perhaps, the entire company. Unfortunately, a widespread practice has taken root within many development teams due to a common misperception. That is, a system on chip (SoC) full of multiple heterogeneous embedded processors will work as intended if individual IP blocks have been verified on their own.

Instead of thinking like a systems integrator, development teams often assume that because the IP, fabric and memory subsystem have all been tested, the entire flow should work. After all, if each IP block works, the software should be able to stitch them together into a working, useable device ready for shipping.

Another SoC development myth holds that power and clock management can be tested at the block level rather than the system level. The motto seems to: Just stitch the blocks together and ship the chip.

It should be apparent –– even to those of us in non-technical professions –– that while the IP may be rigorously tested, cross interactions among the IP can create scenarios where the sum of the parts is greater than the whole. This leads to multiple failures in the system once applied to real-life devices.

Who hasn’t had their workstations or the latest cutting- edge technology –– the ubiquitous smartphone –– hang on them when trying to multitask across programs while in a rush to meet a project deadline?

It is surprising how many chip development teams overlook interactions at various points of convergence where IP blocks meet. This is either because they run out of time before tapeout or because they simply do not have adequate tools to complete the task. According to my technical colleagues, such points of convergence include bus fabrics, memories, interrupts, I/O ports and system-management components –– power and clock control, sideband communications and producer/consumer handoffs, for example. Or, all of them, which means the entire chip, guts and all. 

Does this sound a bit like the challenges faced by an old fashioned systems integrator? It should, because that’s how SoC development teams should be thinking. A systems integrator is a popular –– nix that, important –– job with a government contractor. These engineers need to ensure various components in radar systems, and command, control and communications equipment that track airplanes flying around the globe are all working soundly together –– think North American Aerospace Defense Command (NORAD) in Colorado. Or, those engineers whose job it is to install onboard radar and communications equipment in the very airplanes the radar is tracking. Everyone reading this piece wants systems integrators to do an outstanding job at testing and verifying that the equipment works without resorting to a stitch-and-ship approach.

A system integrator starts with a template or overview of the design, then reviews it and rigorously tests that each black box (or function) works with the next and all the connections are integrated properly. It’s a step-by-step process that could easily be overlaid on a SoC design specification.

This process is necessary because stitch and ship doesn’t work for systems integrators and is a lousy strategy for SoC verification as well. Much like a systems integrator’s template, development teams should develop a SoC verification methodology that exercises a wide range of functional scenarios, encompassing cross-interactions and covering all points of convergence.

Graph-based scenario models –– or templates, using the systems integrator term –– capture intended behavior of the IP blocks. These can be combined to create scenario models for major subsystems or the complete SoC. Breker’s TrekSoC, for example, can “read” these scenario models intelligently and then automatically generate self-verifying C test cases to run on multiple heterogeneous embedded processors within the SoC. These test cases thoroughly exercise the system-level chip functionality, running end-to-end user scenarios with randomized variations, harnessing the power of the embedded processors to verify the SoC “from the inside out.” This approach, while still emerging in the electronics industry, has been used on cutting-edge SoC development projects.

SoC verification is hard and only getting harder. Without rigorous, full-chip verification, the SoC could have serious problems and serious consequences in the marketplace, failing to perform to its full potential. Re-fabricating the SoC will cost $1 million or more and cause a multi-week schedule slip. The delay in product introduction could cost tens of millions of dollars in lost revenue, kill the product or even kill the company. Instead of stitching a chip together and shipping it, SoC development teams must think systems integration and use advanced verification techniques such as scenario models and self-verifying C test cases to ensure a successful project outcome.

About the author