The wide range of different types and models of mobile phones can be a significant problem for developers of software. While the majority of phones are based on the ARM processor architecture, there are many different implementations with processor cores from the ARM9 and ARM11 families, and different ranges of peripherals from suppliers such as Texas Instruments, Qualcomm or Atmel.
Developing and testing new applications and games for a wide range of different handset models can be difficult with this variety of hardware. To develop the best games requires a significant team of software engineers, and a developer wants them to focus on providing the best gaming experience, not on porting and testing the code to many different phone platforms. Similarly, a handset vendor wants to provide new games for new handsets twice a year, so the development has to be done quickly – another problem if the code has to be ported to different platforms and thoroughly tested.
Applications that require secure transactions or power management have to dig down deep into the processor to take advantage of hardware features, so linking tightly to the ARM core is vital. Phones run a variety of execution environments, so being able to fully test the applications on Linux, Symbian and Microsoft operating systems is a significant requirement.
Simulation technology is now emerging that helps the software developer write and test high level application code on the desired operating system, running on a particular hardware platform, long before the hardware becomes available. This allows the developer to start earlier and write the heart of the code just once, testing it out on any variants of the hardware early in the development cycle.
Simulation tools from ARM, CoWare, VaST, Virtio/Synopsys and Virtutech now allow the developer to write and test code much earlier in the development cycle, allowing applications to come to market faster and with higher quality. An ecosystem of tools and models is emerging, driven by the needs of the software developer and by open standards for writing models as shown in Figure 1.
1. Designers can Combine different models to write application code as early as possible in the design cycle of a mobile terminal
These simulation tools use models of the hardware that run at real time speeds. Unlike the models used for simulating hardware during the development of the chips, these models provide a programmer's view (PV) of the underlying hardware. These models are stripped down to be functionally accurate but provide the execution speed that is necessary to realistically simulate the application software running on the target hardware.
Recently the OSCI standards group has been working on standards for the PV models and interfaces which allow models from different sources to be combined in one simulation. These high-level functional models can use the Application Programming Interfaces (APIs) of the host operating system to access the computer's resources, such as audio and video subsystems, allowing an abstract model to be created very quickly. Later in the development cycle the models can be made functionally equivalent at the register and bit level to the real hardware, allowing the developer to write hardware dependent software, such as device drivers and boot code. This in turn allows the code to be optimized to get the best performance and the longest battery life out of the handset.
But some software developers still need assistance in putting these models together and making them run effectively. The application developers are not hardware engineers and do not want to be developing complex models of hardware.
To tackle this, some of the simulation tool providers offer a service to integrate the models, often keeping control of the underlying intellectual property of the models. Although this process can well serve application developers' needs, it can be expensive and potentially time consuming, limiting its use by smaller application developers.
An alternative approach is to offer a reference design of a chipset or electronic device. This reference design combines models of the processor core with models of the peripherals such as an LCD display, keyboard and communication interfaces. For example, an Ethernet controller allows pre-prepared data on a file basis to be pulled in for testing, or even allows the simulation model to connect to the Internet to show how the code would respond connected to a network in the real world.
A skin around the simulator also allows the end device itself to be simulated on the PC. This can provide a view of the handset with the keyboard and screen so that the user interface can be fully tested to check the quality of the user experience. Figure 2 illustrates this.
2. A software application executes on top of a virtual platform and communicates with the underlying operating system of the host machine
The reference platform also allows the software developer to swap in different models for different peripherals, depending on the target hardware for the code. Even custom and existing legacy models can be dropped into the reference platform to exactly match the target hardware. Some of the tools, such as the RealView System Generator from ARM, have an open interface for developing custom models. The specifications of the Open SystemC Initiative (OSCI) also simplify the development of models in-house either by the application developer or the hardware provider, strengthening the ecosystem of models that are available and providing more value for the application developer.
In the past, the issue with this kind of software development platform has been performance. Now a combination of the increasing performance of PC workstations and the new generation of very fast models of processor cores allows simulations that run at real time speeds. This is especially important as the simulation has to run the operating system and then run the application on top.
In the case of ARM, processor cores are themselves developed from cycle-accurate (CA) models and checked using an extensive suite of test programs. This same suite is used by ARM to test the functional accuracy of the PV models used for software simulation. The key is that these models are written to get the highest possible performance, over 100 million instructions per second (MIPS) for a single-processor system on a typical PC, by optimizing the instruction execution inside the processor core and the interfaces to both memory and peripherals. Processor core models typically employ a technique called dynamic binary translation to achieve the required performance. Table 1 shows the result of measurements taken using the ARM realView platform.
Click here for Fig.3
3. The performance of the simulation models produced by the RealView System Generator from ARM
The software running on the PV models is then verified back against the hardware to ensure it is functionally correct, so the software developer can be assured that the code will run in exactly the same way on the hardware. This combination of simulation speed and accuracy is vital.
The simulator also has to link closely with the debug and software development environment. Being able to simulate the code is a start, but the code developers need to be able to identify problem areas, use break points and have access to the state of the system when something goes wrong.
It helps significantly if the development tools can access the debug interface of the simulation models, rather than making use of a system resource such as virtual communications port. This may be the only option when using the generic gdb debugger for the Linux operating system or other third party development tools. In the best case, however, having the debugger and compiler closely coupled to the simulator provides the developer with a clear view of the operation of the code, and the ability to optimize for performance or code size.
Using tools from the model supplier also means code can be developed, debugged and simulated for the whole family of ARM cores, from the ARM9 through the ARM11 today and to the latest cores such as the Cortex-A8, which are not yet available in hardware and so do not have third-party debuggers. This saves substantial time in the development of applications and allows one code base to be fully tested and optimized across a range of different hardware platforms, and different operating systems.
These platforms are not dependent on real hardware and can be deployed electronically, so that software teams around the world can use the same models to combine different applications and test out the whole software environment. This saves the cost and inconvenience of shipping development boards, and therefore improves productivity of a design team.
High-level simulation is now viable with the necessary performance level in the PC, very fast processor models and a growing ecosystem of standards-based models available for developers to customize their own platforms. Linking with development tools that understand the simulation helps to significantly reduce the time it takes to develop new applications, as well as reduce development cost and improve the quality of end applications.
About the Author:
Mark Snook is product manager for the ARM RealView System Generator simulation environment at ARM Ltd., Cambridge UK.