Embedded design using simulation and virtualization

Embedded design using simulation and virtualization

System software design method offers the ability to watch what’s happening in all system devices

BY EDDIE GLENN
Virtutech, San Jose, CA
http://www.virtutech.com

Virtualization has revolutionized IT by providing flexibility, convenience, and increased robustness of IT infrastructures. Virtualization has also helped software developers designing for standard computers with big benefits over what physical target hardware offers, including the ability to:

Easily manage multiple virtual machine configurations (such as different OS versions, different amounts of memory, etc).

Test/debug their software on these different configurations.

Test/debug in relative isolation without fear of crashing their own workstation.

But what about the rest of software development community – those developing apps that run on embedded appliances, non-PC/workstation/standard computers, non-x86 architectures, those trying to maintain a legacy application on antiquated hardware or an app on hardware that is in short supply or that doesn’t yet exist?

Full system simulation

Full system simulation provides virtualization capabilities to these developers, even for non-PC hardware configurations. As its name implies, full system simulation provides the ability to simulate a complete system, including its microprocessor(s), memory, I/O peripherals, disk drives, networking connectivity, etc.

But, instead of thinking of full system simulation as a collection of devices, think of it in terms of the final system such as an avionics rack for a new airplane, a telecommunications base station, networking equipment, an automotive or industrial engine controller, a satellite, or a high-end computing server.

With full system simulation, software developers have a virtual representation of their entire system running on their desktop or laptop PC. Developers load their software on the virtual system much as they would with physical target hardware using their standard source code debugger, compilers, and linkers. One notable difference, however, is that the virtual system can travel with them so they can develop, debug, and test while on the road.

Capabilities

The virtual system provides more debug capabilities than physical hardware with features such as reverse execution, the ability to save and reload the complete system state, and the ability to peer into, and have control over, virtual system devices. This offers the software engineer a complimentary dimension into debugging and test. Unlike typical debugging where one watches the state of the microprocessor’s registers and program counter, full system simulation offers the ability to watch what is happening in all system devices.

For example, if you are debugging a problem with a UART driver, you can set breakpoints for certain conditions within the UART itself, beyond what the processor can see. Developers can even change the state of these devices to insert virtual hardware faults into the system to test how the software detects and recovers from a hardware fault.

Full system simulation helps the software developer debug at the system level instead of at the individual board level. Have you ever tried to:

Debug an intermittent problem that occurred as a multiboard system was booting and appeared to be related to slight timing variations between the boards?

Simultaneously stop all boards of a system at exactly the same time to debug a problem that manifests itself on board C, but probably originated on board A?

Debug a software problem that seemed to occur within a device driver for an internal SoC I/O peripheral and discover that you had limited visibility to what was actually occurring within the SoC?

Requirements

Full system simulation allows you to handle all of these things. It can be a powerful solution to very difficult software and system problems. However, a few important tenets must be followed to make full system simulation a practical reality:

• The simulation needs to be fast enough to run full software loads, no matter how complex the full system is.

• The simulation must be scalable. If you can’t simulate the entire system (be it 5, 10, or 100 boards), then its usefulness will be limited.

• The simulation environment must both support a large library of out-of-the-box models and give users the means to quickly create models of their own target system.

• The simulation environment needs to provide control of and visibility into the entire simulated system.

One example of a simulation system is Virtutech’s Simics a full system simulator that supports these tenets. Designers can run simulations of full systems, sometimes containing hundreds of different boards with heterogeneous target architectures.

Target application code, the real-time operating system, drivers, and firmware all can be debugged, tested, and executed using the virtualized target hardware. A virtualized software development environment allows one to run the exact same binary that would run on the physical target. This means there is no need for RTOS/OS API abstraction layers, stubbed-out drivers or firmware, or multiple-build scripts that build the software one way for a production environment and another for a stubbed-out environment.

A virtualized software development environment provides:

• An instruction set simulator for the microprocessor(s) in the target hardware.

• Behavioral simulation of all devices in the target hardware that the target software interacts with.

• Connections between, and among, simulated targets and the real-world (e.g., networks like Ethernet, MIL-STD-1553, ARINC 429, SpaceWire, FireWire, USB, ATM, and other mechanisms like disk images, memory images, etc.).

• The ability to use the same tools (such as compilers, linkers, debuggers, IDEs, and RTOSs) and processes that the software developer would use with the physical hardware. ■

For more on simulation, visit http://www2.electronicproducts.com/Software.aspx.