Virtual prototype for Android HW-SW dev't (Part 2)

In the remainder of this series, we will tackle virtual prototyping usage and early software development by means of a brief case study. The case study is centred on a multi-function sensor controller sub-system which supports an accelerometer, magnetic field, orientation, gyroscope, light, pressure, temperature, and proximity.

The sub-system embeds an ARM Cortex- M3 microcontroller along with generic peripherals such as an interrupt controller, memories, GPIOs, and I2C. The sensor sub-system runs dedicated firmware to proxy the requested sensor data into a shared memory mailbox for communication with the main CPU. The main CPU, an ARM Cortex-A series CPU, runs Linux and Android.

The full integration of the sensor through multiple sub-systems and multiple software layers creates challenges for the responsible software developers (figure 1).

In the following sections, we will introduce how virtual prototyping helps to address those challenges. We will go bottom up and start with the sensor firmware development up to the usage in Android applications.

Creating sensor sub-system virtual prototype
In order to develop firmware for the sensor controller sub-system prior to RTL being available, a stand-alone sub-system virtual prototype (VP) will be created. This means the VP will initially not be integrated into an application platform and solely used for the sub-system firmware. The main sub-system parts, memory map and interrupt configuration is defined as follows:

Using this specification, the sub-system VP can be created using the Virtualizer authoring GUI, as shown in figure 2. The author selects the necessary models from the processor and peripheral model library which is shown on the left hand side of the tools. The connectivity of the reset, clock and interrupt lines can be performed graphically as well as the specification of the memory map. Each bus slave in the platform, such as the peripherals, can be equipped with a target address.

If all models do exist, a VP can be created in a few minutes. As an alternative, the VP can be assembled using a TCL-based scripting interface. Therefore, each action in the GUI corresponds to a TCL command. The user can generate a batch mode authoring script by recording the commands, which are issued during the GUI based assembly.

Later on, the script is a perfect vehicle to create and maintain platform variants with different memory maps, interrupts, etc. Scripting is a much more scalable approach than maintaining many platform variants using a GUI. The script needed to create the sensor sub-system contains ~150 lines including comments. Once the platform is ready, the VP can be compiled and is ready to be used by the software developer.

Sensor sub-system firmware dev't
The sensor firmware communicates with the Linux sensor device driver via a so-called Inter Processor Communication Module (IPCM). This peripheral is located in a shared memory region and is accessible from the main CPU and the embedded controller. The IPCM can send out notifications through interrupts when a new message for the main CPU or the controller has arrived. For this purpose, the IPCM contains some control registers that allow the sending processor to notify the receiving processor. The sensor sub-system controller firmware receives commands such as "read accelerometer" from the main CPU. Therefore, the main CPU writes the required command ID into the IPCM and notifies the controller. The controller interrupt handler wakes up, reads out the command from the IPCM, determines the sensor value from the GPIOs/I2C, and provides the data back into the IPCM. The firmware for the ARM Cortex-M3 microcontroller can be developed using a standard tool chain such as GCC, DS-5/RVDS. The resulting binary image can be loaded directly into the memories using the VP tool infrastructure. Afterwards, the software developer can use his favourite debug tool along with the embedded controller CPU as shown in figure 3.