ARM-based Android hardware-software design using virtual prototypes

October 27, 2012

achimnohl-October 27, 2012

Editor’s Note: In the first in a three part Product How-To series on virtual prototyping, Achim Nohl describes how to use the Synopsys Virtualizer Development Kit (VDK) to do early prototyping. He also explains how to do full software integration of handset hardware in the context of the Android software platform.

The Android Software Development Kit (SDK) [1] enables the software community to develop applications that take advantage of the latest handset features before the handset is even available. SDKs are tailored and extended by handset providers to design devices with their key differentiating product capabilities.

Prominent examples include Kyocera’s SDK support for their dual screen devices, Samsung’s SDK extensions for S-Pen, or LG’s modified SDK for 3D application software development. The core of these SDKs is a simulator based on the QEMU [2] simulation framework. The SDKs guarantee that at the Java level, the programming interface (Android API) is consistent between the real handset and the SDK’s simulator.

However, these SDKs target application developers. The execution and architecture underneath the Java software layer is not guaranteed to match the execution of the real handset. This is due to the fact that the SDKs simulate a generic hardware platform, the so-called “Goldfish” platform. For this reason, SDKs fall short when it comes to full end-to-end hardware/software integration.

In the case of a full integration, the Linux operating system, device drivers, and the Android hardware abstraction layer (HAL) need to be brought up for the specific product hardware. These software layers execute natively on the CPU (native code) in comparison to Android applications that are based on Java (interpreted code). Therefore, the required simulator needs to be able to simulate the exact CPU instruction-set architecture (ISA) as the final product’s CPU would do. Furthermore, other simulated aspects such as memory maps, interrupts, and peripherals need to match the hardware, as they are directly accessed by lower level software development.

Typical SDKs have not been designed to fulfill the lower level requirements, yet the software developer requires deeper transparency to such functionality and a way to program at the register level. We'll take the integration of a specific new sensor hardware peripheral as an example.

Here, the device driver has to interact with the peripheral through the memory mapped register interface, exactly as it is specified in the sensor’s technical reference manual. The correct implementation of low level functions such as interrupt handlers, clocks, and voltage regulation are important for a complete integration. These details are not reflected by the generic simulation model of a sensor which the typical SDK provides.

Thus, it seems obvious that we need to wait until hardware becomes available before we can start the lower level software development. But, due to time-to-market pressure and the short product amortization windows (time in market), this is not an option anymore. Software has to be almost entirely ready by the time the first hardware samples arrive. This is not only comprised of the product’s software stack, but also the test and validation software, which is required for the quality assurance and sign-off process. Furthermore, this doesn’t take into account the entire handset supply chain, comprising IP suppliers, semiconductor firms, and OEMs. Each of these stakeholders has a different software focus.

IP Supplier’s Software
IP companies supply key IP functionality to the semiconductor firms. The IP is then integrated into a system-on-chip (SoC). The integration is conducted at both the hardware level and the software level. Knowing that software development is 50 percent of the engineering cost, IP suppliers cannot afford to fall short by not providing the respective software integration out of the box. Each semiconductor will perform its own SoC specific IP hardware integration. However, on the software side a manageable set of operating systems (Android, Windows etc.) will be used among all semiconductors and OEMs. The IP supplier’s software integration is comprised of the OS-specific device drivers and middleware, which are expected by the semis and ultimately integrated as modules into the semi’s SoC OS board-support package (BSP). In a BSP, the driver is configured for board-specific properties such as memory map, interrupts, clocks, and voltages.

Thus, driver and middleware development can be done outside the SoC context. As an example, a generic prototyping board, such as the ARM Versatile Express prototyping system [3] can be used. For this system, a large set of operating systems are maintained and developed by the software community (e.g. Linaro [4]) and can be leveraged by the IP provider as a development framework. The downside is that RTL is required in order to start software development since the IP has to be mapped onto an FPGA. This has severe consequences since even the IP providers need to be ready with their software long before they can provide stable RTL. This demand is coming from the semiconductor software project timeline as well as from the company’s ability to win customers early.

Semiconductor software
Semiconductor firms need to provide board support packages (BSP) for all major operating systems to their customers. The heart of a BSP is an operating system kernel, which is ported to the semiconductor’s specific SoC. A core BSP is typically comprised of approximately 20,000 lines of platform-specific code. Lower level properties, such as memory maps, interrupts, clocks, voltages, device driver configurations, as well as higher level functions such as CPU run-management, system power management, security, and others are also part of the core BSP. In contrast to the IP supplier, the semi is concerned with the whole platform rather than a single piece of IP. Thus, the completion of the low-level software requires a platform-specific prototype.

In contrast to the IP supplier use case, a generic prototyping system that can be extended by individual IP titles is not sufficient. For the IP supplier use case, large capacity FPGA prototyping systems are leveraged, such as the Synopsys HAPS Family of FPGA-Based Prototyping Solutions [5]. But again, software development cannot wait until RTL is available and therefore a pre-RTL prototyping solution is necessary.

Virtual prototyping and virtualizer development kits
Virtual prototyping is a method of prototyping a hardware system before RTL becomes available. Instead of mapping hardware on an FPGA, a virtual prototype simulates the hardware system on a host PC and runs the final binary software images of the entire software stack including ROM code, operating system, and higher level software platforms such as Android. In contrast to the SDK for Android, a virtual prototype mimics the hardware at the lowest level observable by the software: the CPU instruction set, platform memory map, and interrupts.

Still, the simulation speed of a virtual prototype is well within acceptable ranges for the software developer and scales between two to fifty times slower than real time. This depends mainly on the complexity and scope of the hardware modeled. Another advantage of virtual prototypes, next to their earlier availability, is rooted in the outstanding determinism, control, and visibility that enable powerful debug and test techniques, which will be examined later in this article.

A virtual prototype is constructed using abstract functional models of the hardware components such as the CPUs and peripherals. The Synopsys Virtualizer [6] technology provides an environment that is based on the IEEE 1666 SystemC TLM-2.0 model interoperability industry standard. Using dedicated authoring tools, a virtual prototype can be constructed with custom TLM-2.0 models or by leveraging a large library of commodity models (such as ARM CortexA,R,M series including big.LITTLE, ARM PrimeCell, Synopsys DesignWare, etc.). Models from multiple vendors are also provided through internet platforms such as TLMCentral.com. Model authoring tools for custom hardware also exist, such as the Synopsys TLMCreator. TLMCreator greatly facilitates the creation of custom TLM-2.0 compliant models.

Virtual prototyping has become an established software development enabler for major semiconductors as announced by Texas Instruments [7] in the context of the OMAP ecosystem. An illustration of a virtual prototype, the embedded software and the tool ecosystem is shown in Figure 1.



Click on image to enlarge.

Figure 1 - Virtual Prototype Example

Some virtual prototypes may abstract some functions of certain peripherals away if they are not relevant to the scope of the software development. The ability to abstract away dedicated functions is an advantage of virtual prototypes. It enables control over the complexity of software development and allows for an optimally staged software development plan. On the other hand, physical hardware requires bringing up complex boot ROM code before the OS porting can even start. A virtual prototype allows for greater flexibility here, where functions of the boot code, such as loading kernel images into flash memory, are an implicit part of the virtual prototype tool capabilities. Now, boot ROM code development and OS bring-up can be performed independently from each other, even in parallel or reversed order.

Advantages of virtual prototyping
An advantage of using virtual prototypes for software development is that the software developer can use the same embedded software build and debug tools as can be used with hardware. The debug server, which is an implicit part of the generic infrastructure, provides instant “stop-mode” connectivity to 3rd party debug tools. The Virtualizer debug server supports the most prominent debug tools, such as ARM’s DS-5/RVDS, Lauterbach’s Trace32, GNU’s gdb, etc.

Moreover, any other debugger that connects to a hardware target can connect to a virtual prototype using virtual IO in “run-mode”. As an example, the Eclipse SDK for Android can connect to the Android-Debug-Bridge (adb) software daemon through the virtual IO capabilities of the Ethernet, such as shown in Figure 2.


Figure 2 - Debugging Options

In the case of stop-mode debugging, the virtual prototype ensures synchronous control of the entire system. When execution is suspended by one software debugger, the system time is frozen from the perspective of the embedded software. This debugging mode is fully non-intrusive, as the software is unable to recognize that the system has been halted for the purpose of debugging. No timers will expire, and a consistent, non-transient system state is presented to the developer. This is especially helpful for kernel level debugging. A driver in the kernel can be debugged step by step without violating any time-outs. Integrated debugging with the user-space such as the Android HAL can be performed instantly without any setup hassle (e.g. starting gdb-sever, injecting wait for debugger software loops, etc.).

Virtualizer Development Kits
In many cases the entire SoC is not the focus. IP suppliers, for example, are singularly focused on driver development for just the IP and not the complete SoC. Bringing up drivers and middleware for the company’s specific IP can be done in the context of a more generic platform as introduced earlier. For this type of development activity, Synopsys provides out-of-the-box VDKs [8] for major hardware platforms.

An example of such a VDK is the VDK family for ARM Cortex processors which is aligned with the well-known ARM Versatile Express prototyping system. With this VDK, the entire software ecosystem that exists around Versatile Express (boot code, operating system, Android-ports, documentation, application notes) can be leveraged, resulting in the ability to use Linux kernel and Android file system images that have been built for Versatile Express and can be used out-of-the-box with the VDK.

Furthermore, configurations, and makefiles created for Versatile Express can be used to re-build the Linux kernel or Android for the VDK, saving software developers a great amount of time and helping them to focus their efforts on hardware/software integration of specific hardware components. For this purpose, the VDK can be extended with custom peripheral models or even more complex subsystems.



Click on image to enlarge.

Figure 3 - Virtualizer Development Kit (VDK) and Ecosystem

This is very similar to the real hardware where custom FPGA daughterboards can be stacked on the Versatile Express motherboard. From the embedded software perspective, the VDK follows the same rules (interrupts, memory map) for these extensions. But, instead of using FPGAs the extension can be done using TLM models long before RTL becomes available.

Part 2: Building Android’s multifunction sensor controller subsystem

Part 3: Integrating Android's HAL

Achim Nohl is a technical marketing manager for Virtual Prototypes at Synopsys. He publishes technical articles, conference papers, and blog posts about developing embedded software using virtual prototypes. His specialty is bringing up firmware, driver,s and operating systems for the most recent CPUs and IPs. Achim holds a degree in Electrical Engineering from the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany. Before joining Synopsys, Achim worked in various engineering and marketing roles for LISATek and CoWare.

References
1. Android SDK
2. Qemu
3. ARM Versatile Express
4. Linaro
5. HAPS Family of FPGA-Based Prototyping Solutions
6. Virtualizer
7. TI OMAP
8. Virtual Prototype Creation and Development Kits

Loading comments...

Parts Search Datasheets.com

KNOWLEDGE CENTER