Reusable Device Simulation Models for Embedded System Virtual Platforms

By Zeeshan Anwar, Mentor Graphics
Altrincham, United Kingdom

Abstract:

As embedded systems hardware is becoming more powerful, the demand for high quality, sophisticated and compelling applications is increasing. In addition to that, due to fierce competition in the embedded devices market, the development cycle needs to be shorter for the introduction of new and improved devices. This has led to the majority of the embedded application developer community to recourse of reusable legacy software and sophisticated development tools to ease the pressure. Embedded system virtual platforms constitute one such class of embedded development tools that replace the use of target hardware reference boards for faster and easier embedded application development. Virtual platforms are easier to set up and use, and reduce the time and effort required for embedded application development.

This paper discusses the class of virtual platforms called host simulations. With host simulation, the embedded application code is compiled for the host processor using native compilers and executed directly on the host machine. Host simulation would require the simulation models of all the peripheral devices used by the application for its execution on a host machine. If the device simulation models for one target reference board have been carefully designed and implemented in a host simulation, they can be reused to simulate other reference boards with similar peripheral devices. This paper presents the characteristics of reusable device simulation models, and the methods to design and implement them. It also discusses the steps required to execute an embedded application code on a host machine using host simulation.

Dilemma of Embedded Application Development:

Application software in an embedded system is directly and indirectly dependent on many other low-level software components. Figure 1 shows a block diagram of different software and hardware components of a typical embedded system. The target hardware has an LCD display with a touch panel and a keypad. The application software displays graphics on the LCD screen, and reads user input from the touch panel and keypad. The application code uses Application Programmer Interface (API) functions and structures provided by generic middleware and a Real Time Operating System (RTOS) kernel. The generic middleware code requires device drivers and the RTOS requires target specific components for their execution. The device drivers and the target specific components of the RTOS kernel will execute only if the target hardware is present. Consequently, even when the application code does not directly depend on the target hardware, it cannot execute without it as other software components in the system depend on the target hardware for their execution. Therefore, the embedded application developer will require target hardware to develop and test his application code. Target hardware for embedded application development is usually available in the form of hardware reference boards.

Companies developing products based on embedded systems understand the fact that high quality and unique application software plays an important role in the differentiation of their products from their competitors. As a result, the majority of embedded software developers are engaged in developing differentiating, high quality applications using off-the-shelf middleware, device drivers and RTOS kernels. The dilemma faced by the embedded system application developers is that using hardware reference boards for application development is both expensive and difficult. Buying hardware reference boards for each application developer increases product development costs. Hardware reference boards require specialized development tools and connection probes that further add to the development cost. In addition, hardware reference boards are difficult to set-up and use. The situation becomes even worse if it is yet to be decided which hardware should be used. In this case, the dependency on a hardware reference board will delay the application development until this decision is made. All of these factors make hardware reference boards an unfavourable choice for embedded system application software development.

 

Figure 1: Block diagram of a typical embedded system showing different software and hardware components

The Solution: Host Simulation:

Host simulation of an embedded system provides host-based simulation models of target hardware peripheral devices so that the target-dependent code components could be executed on a host machine without using the hardware reference boards. The host simulation can be further extended by writing the device driver for the simulation models of peripheral devices and a RTOS kernel simulation model that runs on the host machine. When using host simulation, the application and generic middleware code is compiled using native host compilers and executed directly on the host machine. The real device drivers are replaced with the simulated device drivers that work with the peripheral devices simulation models. The real RTOS is replaced by its simulation model that can be executed on the host machine. Figure 2 shows the effect of using host simulation on the block diagram of the same embedded system already shown in Figure 1.

With host simulation, a hardware peripheral device simulation model should be generic in nature, for example, it should not simulate a peripheral device of a specific hardware vendor with a specific set of API registers. Therefore, it could be used to simulate similar peripheral devices for different hardware reference boards. As an example, if two hardware reference boards have LCD display screens from different vendors, the same LCD display simulation model could be used to simulate the LCD display for both hardware reference boards. Since the device simulation models in a host simulation are reusable in nature, it will not be required to create new device simulation models and their simulated drivers for each new hardware reference board. Similarly, while creating a host-based simulation model of an RTOS kernel, only the target specific components are changed to use host operating system. The API provided by the RTOS kernel simulation model remains same. As a result the RTOS simulation model is reusable in nature and can be used to replace the RTOS port for any hardware reference board.

 

Figure 2: Block diagram of a typical embedded system using host simulation on a host machine instead of target hardware

Host Simulation vs. ISS-based Virtual Platforms:

The host simulation being discussed in this paper has certain advantages over Instruction Set Simulator (ISS) based virtual platforms [4, 5, 6] for embedded system application development [1].

• Host simulation does not need an ISS for its operation as it is not dependent on a specific target processor. Whereas, an ISS-based virtual platform will always require an ISS for the target processor.
• In an ISS-based virtual platform, the ISS executes the application code instruction. This has its toll on the execution speed. Even the fast processor models like QEMU [4] and OVP [3] are limited in their execution speed. As the user application code executes directly on the host processor in a host simulation, it provides the fastest execution environment among all the available types of virtual platforms.
• An ISS-based virtual platform will require accurate hardware simulation models with precise API register interface for the peripheral devices. As the similar peripheral devices from different hardware vendors normally have different API registers, new simulation models will be required to create virtual platforms for different target hardware boards. Whereas, in a host simulation, same simulation models of peripheral devices can be reused to create virtual platforms of different target hardware.
• As the host simulation is not dependent on a specific target hardware processors and peripheral devices, it can be used to start application development even before the target hardware is decided. This is not true for ISS-based virtual platforms.

Creating Reusable Simulation Models of Hardware Peripheral Devices:

A reusable peripheral device simulation model should simulate the functions offered by most of the devices in its category. As an example, a UART simulation model should provide common functions available in majority of UART controllers. Moreover, it should be easily portable to multiple host platforms with minimum change in the code.

Most hardware peripheral devices (e.g. communication ports, storage devices, display devices) are composed of some or all of the following functional units as shown in Figure 3.

• Device engine
• Control unit
• Status unit
• User data Input/Output (I/O) unit
• Data transfer or storage unit
• Interrupt generation unit

A hardware device simulation model can be created by simulating each of its functional units as discussed below:

1. Device Engine Simulation

The device engine or state machine combines different functional units to act as a single device. A device engine represents the top level design of device too. Therefore, the first step in the creation of a device simulation model should be creating its engine simulation.  As an example, while developing simulation model of hardware UART, its engine simulation design will involve deciding if the simulation model is a single or multithreaded application, how to implement a data communication mechanism, how the data will be transferred from the data I/O unit to the data transfer unit, etc.

2. Control Unit Simulation

The control unit of a hardware peripheral device simulation model should implement device control functions such as device initializing the device, selecting mode of operation, and enabling and disabling interrupts. The control unit of a device simulation model normally provides API functions and structures instead of registers.

 

Figure 3 : Different components in a peripheral device simulation model and a simulated device driver.  

Status Unit Simulation

The status unit of a hardware peripheral device is use by the device driver to check device status during its operation. The device status unit simulation should provide API functions to get the status of simulated device during its operation.

Data Input and Output (I/O) Unit Simulation

The data I/O unit sends the user data to device and reads the data from the device. The simulation of this unit should provide API functions for user data I/O. If data I/O unit of a device provides FIFO buffers for temporary data storage, the FIFO buffers should be simulated, too.

Data Transfer or Storage Unit Simulation

If the device receives the data from the user application, it is either transferred on a communication bus for some other device, stored in a memory location, or displayed on the screen. Similarly, the data transfer or storage unit sends the data back to the device driver when new data is received from another device on a communication bus or when the application requests to read the stored data. The data transfer and storage unit works in collaboration with the data I/O unit to perform its operation. The data transfer unit should be simulated such that the user data could be transferred to the other simulated devices on a simulated bus. The data storage unit can be simulated using the file system on the host operating system.

Interrupt Generation Unit

The interrupt generation unit of a hardware peripheral device generates hardware interrupts for the application to let the application know of certain events happening in the device. As an example, when the device receives new data for the application, a hardware interrupt is generated to let the application know of the availability of new data. The interrupt generation unit of a device can be simulated using the operating system’s event mechanism or using callback functions.

An Example: EDGE SimTest UART Simulation Model

This example illustrates a generic simulation model for a UART controller available with EDGE SimTest[2]. EDGE SimTest[2] is an embedded system simulation and prototyping tool that provides generic simulation models of a number of hardware peripheral devices. It also provides basic building blocks to conveniently create new simulation models. EDGE SimTest provides two different types of UART simulation models:

• A pure virtual UART simulation model
• A UART simulation model using PC serial port for serial data transfer

The design of a pure virtual UART model is simpler and easy to explain, therefore, only the pure virtual UART simulation model will be discussed here. For the sake of simplicity, vuart will be used to refer to EDGE SimTest[2] pure virtual UART simulation model.

vuart has been implemented in C language. It provides the basic UART data transfer functionality with four API functions and a device initialization structure. The simulation model does not take into account the details of serial communication protocol, i.e. there is no support for parity checking, start and stop bits, and different baud rates in the model. Figure 4 diagrams vuart architecture. SimTest hardware ports are being used to simulate serial bus data transmission. A SimTest hardware port is a basic simulation model building block that provides an inter-process data communication mechanism. It can be associated to a simulated interrupt vector and has a built-in data buffer. SimTest mailboxes are being used to simulate data I/O unit’s FIFO buffers.

The control unit in the simulation model provides an API function for UART initialization with desired parameters specified in an initialization structure. The status unit provides a function to check the status of data I/O FIFOs. The data I/O unit provide API functions to write the data byte to transmitter FIFO and to read a data byte from receiver FIFO.

When a data byte is written to the transmitter FIFO by the simulated device driver using the vuart data output API function, an OS task copies this data byte from transmitter FIFO to serial transmitter bus, a SimTest hardware port. This OS task also generates a simulated interrupt to inform the device driver that the transmitter FIFO is empty. When the data is received on the UART’s receiver bus, a simulated interrupt service routine associated to the receiver line, a SimTest hardware port, is invoked. It copies the data from the receiver line into the receiver FIFO. It also generates an interrupt for the serial driver to handle the received data in receiver FIFO. The device driver then calls vuart’s data input API function to read the data from receiver FIFO.

 

Figure 4: EDGE SimTest pure virtual UART simulation model block diagram

Writing a Simulated Device Driver:

A simulated device driver works with a device simulation model instead of a real hardware device. The API provided by the simulated driver should be the same as provided by the real device driver, so that the middleware code that uses this API could be executed on a host machine without any change. If a real device driver code is available, its simulation can be created modifying the code to use the device simulation model API functions instead of hardware device API registers. This is the easiest method to create a simulated device driver. If no real device driver is already available, a new simulated device driver can be written. Once a peripheral device simulation model is available, the major task left in writing its simulated device driver is to provide API functions and structures to use the device simulation model’s functionality. If the device simulation model generates interrupts for the simulated driver, an interrupt service routine to handle the device interrupt should be implemented too.

A device driver simulation model can also setup interrupts for the user application by registering application callback functions. These callback functions are invoked by the driver to inform the application about the occurrence of various events at the driver level. For example, the application can register a callback function with a device driver that should be called when the driver has placed received data in the application receiver buffer, or when the driver has successfully transmitted application data. Figure 3 shows major components of a typical simulated device driver.

 

Figure 5: EDGE SimTest simulated serial driver components and their interaction with EDGE SimTest pure virtual UART simulation model

Example: EDGE SimTest Simulated Serial Driver

EDGE SimTest provides a simulated serial driver for its UART simulation models. The simulated serial driver provides basic API functions for UART initialization, status checking, data read/write and interrupt handling. Figure 5 shows how the SimTest serial device driver and pure virtual UART simulation models interact with each other.

Execution of an Embedded Application with Host Simulation:

Execution of an embedded application with host simulation on a host machine is quite simple. No special debug probes or target specific tools are required. Following are the major tasks required to execute an embedded application with host simulation on a host machine:

• Instead of a hardware reference board, use simulation models of peripheral devices
• Instead of real device drivers, use simulated device drivers for simulation models of peripheral devices. If the API provided by simulated device driver is different from that of the real device drivers, then the middleware code might require changes to use the simulated device drivers.
• If an RTOS is required by the application, middleware or simulated device drivers, its simulated model should be used.
• A host compiler should be used to build the code instead of a target compiler.
• A host debugger will be used instead of the target debugger to debug the application

Conclusion:

Application software development for embedded systems is expensive, difficult and time consuming when using target hardware reference boards. The use of host simulation for embedded application development is cheaper and easier. Host simulation is faster than the ISS-based virtual platforms. It is also cheaper as it does not need an ISS and accurate simulation models of peripheral devices. Above all, it can be reused to simulate different target hardware reference boards with a similar set of peripheral devices as the peripheral device simulation models in a host simulation do not simulate a device from a specific vendor. Moreover, migration of an embedded application from target hardware to host simulation is quite straightforward. All of these factors make host simulation-based virtual platforms a preferred solution for embedded systems application software development.

References:

[1] Ville-Veikko Helppi, “Conquering the Complexity of Today’s Embedded Systems:

Host-Based vs. Target-Based Development”, Embedded World Conference, 2009.

[2] EDGE SimTest, http://www.mentor.com/

[3] Brian Bailey, “System Level Virtual Prototyping becomes a reality with OVP donation from Imperas”, http://www.ovpworld.org/.

[4] QEMU Open Processor Emulator, http://www.qemu.org/.

[5] VAST Embedded Software Development Solutions, http://www.vastsystems.com/solutions-embedded-software.html.

[6] Synopsys Virtual Platform Technologies for Embedded Software Development, http://www.synopsys.com/Tools/SLD/VirtualPrototyping/Pages/default.aspx