Android hardware-software design using virtual prototypes - Part 2: Building a sensor subsystem
Editor’s Note: In the second of a three-part series of articles on virtual prototyping, Achim Nohl explains how to use the Synopsys Virtualizer Development Kit (VDK) and describes the hardware/software integration flow for a sensor subsystem for use in an Android mobile device.
For the remainder of this series, we will illustrate virtual prototyping usage and early software development by means of a brief case study. The case study is centered on a multi-function sensor controller subsystem which supports an accelerometer, magnetic field, orientation, gyroscope, light, pressure, temperature, and proximity.
The subsystem embeds an ARM Cortex- M3 microcontroller along with generic peripherals such as an interrupt controller, memories, GPIOs, and I2C. The sensor subsystem 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 subsystems and multiple software layers creates challenges for the responsible software developers, as shown in Figure 4.
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 a sensor subsystem virtual prototype
In order to develop firmware for the sensor controller subsystem prior to RTL being available, a standalone subsystem virtual prototype (VP) will be created. This means the VP will initially not be integrated into an application platform and solely used for the subsystem firmware. The main subsystem parts, memory map and interrupt configuration is defined as follows:
Click on image to enlarge.
Using this specification, the subsystem VP can be created using the Virtualizer authoring GUI, as shown in Figure 5. 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.
Click on image to enlarge.
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 subsystem 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.