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
- DevOps meets ALM in the Cloud - Cloud DevOps PaaS To improve software delivery performance and effectiveness, teams need automation, governance, architecture best practices, and increased team collaboration. Find out more.
- Coding with JRebel: Java Forever Changed With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with...
- What Developers Want: The End of Application Redeploys Eliminate application restarts in Java with JRebel! JRebel is a JVM plugin that eliminates application redeploys from the Java development cycle, a process...
- How a German energy company saved 1 day per week of development time with JRebel Check out the following case study to see how Heliocentris, a global energy supply and efficiency company deployed a development solution that was...