Full System Simulation: Software Development's Missing Link

Computerworld - The primary challenge in delivering an electronic system is developing and testing the software. Systems aren't just computerlike boxes; they're complex products, from planes to cell phones. The Airbus 380, for example, is expected to contain more than 1 billion lines of code, while a cell phone can contain several million.

The process of delivering a working electronic system has moved away from the traditional one, where designers finalized the hardware design, then completed the software, then performed the final system integration. Instead, driven by cost and time-to-market pressures, software development using full system simulation is becoming the technique of choice.

In the past, two approaches to software development predominated: host-based, and hardware-based.

In host-based development, designers would first create a test scaffold on a desktop computer -- though the final product would eventually ship on some other platform. The vain hope was that, for example, development on an Intel PC using this scaffold would be accurate enough that it would run on a MIPS processor with a real-time operating system.

Because the weaknesses of this approach wouldn't surface until final system integration, this phase of the project would ultimately produce an unpredictable, prolonged schedule. The advantage of this approach is that the code runs very fast, because it is natively compiled for the Intel processor. The obvious disadvantage is that it doesn't reflect how the real system will behave.

In addition, this approach clearly won't work for developing device drivers, operating system kernels and any other software that interacts intimately with the underlying hardware. The development of the "golden" code -- the code that will actually ship with the product -- doesn't begin until hardware is available.

Conversely, hardware-based development uses either real hardware or a surrogate, typically built using field-programmable gate-arrays (FPGA). Real hardware has the advantage of being as accurate a model as possible.

The big disadvantage is that the hardware has to actually exist, or at least be sufficiently well advanced that the FPGAs can be programmed. Even then, hardware isn't an especially friendly debugging environment. Worse, software and hardware development are unnecessarily serialized.

Furthermore, the device being designed doesn't operate in isolation. For example, a set-top box may need to communicate with a video server, and perhaps another billing server, while the servers need to communicate with a PC used for management control. Because of the need to produce an accurate test environment, systems companies using this approach spend tens or hundreds of millions of dollars on test racks.

Advances in simulation technology, coupled with the inexorable increase in the computing power of off-the-shelf