Tools for Test and Debug : System C: a realistic SoC debug strategy

System C: a realistic SoC debug strategy
By Pete Hardee, Director, Product Marketing, CoWare Inc., Santa Clara, Calif., EE Times
June 4, 2002 (11:57 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020531S0027

As Moore's Law steams ahead, the resulting rush to retool for ever-smaller geometries has led to the realization by most leading companies designing systems-on-chip that the emphasis in SoCs is on that "S," for system. In other words, it's not what they can do, it's what they can do with it.

The art of applying SoCs to real systems is dominated by software. So it is easy to see why C/C++-based design languages are rapidly gaining popularity. Many have mistakenly believed that such languages, like SystemC, aim to replace hardware-description languages, such as Verilog, for pure hardware design at the register transfer level. But that holds very little advantage, and the vast majority of companies backing SystemC, including CoWare, are not trying to replace the Verilog designer.

SystemC is also among a group of design languages and extensions being proposed to raise the abstraction level for hardware verification. Here, SystemC is a stro ng player, but it's also in strong company. The list includes e, OpenVera, Superlog, System Verilog and a few other variants of C/C++.

But SystemC will really make a difference in the area of architecture, the co-design and integration of hardware and software. The reason lies partly in the deliberate choice to extend a software language with nonproprietary extensions to describe hardware and system-level modeling. However, SystemC is merely a language, so a greater part of the reason for success in this area is the availability of tools and methodologies proved to cut design cycles at such leading companies as Fujitsu, Matsushita, Sony and STMicroelectronics.

In the design flow of a traditional embedded system, system integration follows a methodology largely unchanged since the advent of the microprocessor. Software first meets hardware at the prototype stage and an in-circuit emulator (ICE) is plugged in to replace the microprocessor. Then a structured debug methodology is followed.

However, the advent of the SoC presents a serious obstacle to this flow. Not only is there a huge increase in hardware and software complexity in SoC-based embedded systems, but it is clearly not possible to plug in ICE in place of the processor. Attempted solutions of this problem include providing some level of software visibility via JTAG and various other on-chip debug methods. None of those methods is widely accepted to provide sufficient control or visibility to integrate a system.

Even if visibility into the software could be satisfactorily afforded by such methods, the prototype hardware arrives very late in an SoC-based project. And although it is almost always desirable to fix integration problems in software rather than hardware, any major problems with the hardware that are discovered at a late stage in a complex SoC have huge ramifications. These include redesign time, mask costs that typically run into millions of dollars, possible missed fab slots and consequent loss of time-to-m arket.

Gaining popularity as a solution is system integration on a virtual prototype-a simulation model of the SoC before fabrication. Software is run on an instruction set simulator (ISS) model of the processor, and the ISS communicates with a simulation of the rest of the hardware via a bus interface model or bus functional model.

For most processors, debugging the software on an ISS is very much like working with the real processor or with ICE: The same cross-compiler and debugger are available. Tools employing this method today are most commonly HDL-based co-verification tools. However, though those have gained some popularity with hardware verification engineers, most firmware developers regard them as too slow for serious system integration.

Designers have started to create virtual platforms of their SoC designs in C or SystemC for good reasons. First, they can provide an early simulation platform for the system integration that executes much faster than HDL-based co-verification. Second, they can verify the architecture at an early stage of the design process, testing different hardware-software partitions and evaluating the effects of architectural decisions before implementation. After all, by the time they're coding in RTL, the hardware architecture is established and there's little room for flexibility. Third, they can start work on derivative or next-generation designs by reusing the platform before the first-generation design is complete.

Simulating in C or SystemC avoids the need to use the Verilog Program Language Interface (PLI) or VHDL Foreign Language Interface (FLI), both of which are used to hook C-based models or testbenches to HDL simulations. By converting to C, a single executable can be used so there's no need for a PLI or FLI, which become huge bottlenecks in large simulations.

Virtual platforms can, an d should, be used at various abstraction levels, starting with a very simple functional description and then refining toward implementation. As each part (that includes hardware or software) of the design is refined, it can be tested in the context of the entire system. Often, parts of the design that don't interface with the new block being tested can be run at higher levels of abstraction to speed simulations.

It takes only five minutes to simulate four seconds of real-time in untimed C. But that same four seconds of real-time software running on RTL HDL would take about one and a half months. And a gate-level simulation is nearly impossible-it would take more than a year.

In the design of a high-end camcorder, one company found that co-verification of one video frame in C plus RTL took 10 days. However, by moving up to untimed C, 500 video frames could be processed in eight hours prior to architecture design and hardware-software partitioning. This allowed the d esigners to test out their algorithms extensively before implementation in hardware or software, finding bugs early in the design process that might have gone undetected with co-verification.

Verification in C can be done at several levels and those levels can be mixed in any one simulation run. Fujitsu Laboratories recently reported attaining a range of results for ISS/C/C++-based simulation between 50 and 1,000 times faster than those of ISS/RTL-based simulation, with different mixes of cycle-accurate and untimed levels.