The example that is explained in the following is freely available for download here.
The development of personal computer SW is a task that can be completely handled on a PC. For embedded systems there is a different story to tell. Embedded SW is not developed on the embedded system itself. A PC and a cross-compiler are required. To execute the program it needs to be downloaded to the embedded system first and this is where evaluation and verification can become laborious. “Embedded” means that these systems are part of a bigger maybe very complex environment that they should monitor and control. During verification and validation (debugging) it can be impossible to control the environment in such a way that repeatable regression tests are observable and thereby can be debugged. OFFIS chosen strategy relies on intensive system simulations. The system and environment are implemented as executable models. If the abstraction of simulation it is still accurate enough to depict the relevant aspects of the system, it has many advantages:
The implementation we present enables a methodology called virtual platform in the loop simulation (Figure 1), which is an intermediate step towards hardware in the loop simulation. The challenge is here to synchronize two independent simulations so that the simulated time does not diverge and data can be exchanged at the right instant of time. OffisSimLink is a bus peripheral model for the commercial Open Virtual Platform which enables simulating embedded systems running real application code. Attached to the simulated bus of an instruction set simulator it enables the exchange of data with a Matlab/Simulink model via memory mapped IO. Figure 2 depicts the architecture of the implementation.
OVP and Matlab/Simulink are executed in parallel on a Host PC. This can either be one or two individual machines connected via network. OffisSimLink occupies address space in the OVP simulated system on chip. Any read/write transaction to this address space on the bus is forwarded to Matlab/Simulink using Mathworks engine.h API which was used to implement a semihost.dll for data exchange. Both simulations run in parallel and synchronize every defined time period. Matlab/Simulink automatically STOPs when it reaches a synchronization point and will be continued by OffisSimLink after synchronization. The advantage of this synchronization scheme is the full parallel execution of both simulators which delivers best simulation performance in comparison to a mutual exclusive approach. The disadvantage is a loss in simulation accuracy since changes in one of the simulations will be available in the other only every synchronization interval. Since this interval is configurable the disadvantage can be minimized to a tolerable influence on the simulation results depending on the simulation use case.
An example including the OffisSimLink bus peripheral model and its sources are available for download here. The example, as well as OffisSimLink are outcome of OFFIS research projects. The download is not to be mistaken for a product release. Its use is for publishing our concept only and supporting you with your own adaptations and development. OFFIS does not guarantee that the download will run out of the box on your system, will compile without modifications depending on your system or fulfills any standards of quality.
The downloadable sources where developed on a Windows 7 system. It is assumed that you have OVP and Matlab/Simulink installed correctly. The downloadable sources and makefiles will require (easy) modification according to your installation path and versions of these tools.
Please have a look at the following directory structure. You will be required to call “make” in several branches of the directory structure.
Contains the source code (main.c) of the embedded application to be executed on the instruction set simulator. This part resembles to the white box in Figure 2 being labeled “Hello.c”. Calling ”make” will cross-compile the source and generate an ELF (OffisSimLinkDemo.elf). Cross-compilation requires that your OVP includes the ARM tool suite.
Contains the demo Simulink model. It can be opened and modified using your installed Matlab/Simulink. “mySimulink.mdl” resembles to the green box within Figure 2.
Contains the source code for the “Semihost.dll” as shown in Figure 2. Calling ”make” will generate the “model.dll”. You will need to modify the file “Makefile” according to your tool installation paths.
Contains the source code for the OVP bus peripheral model (OffisSimLink (x86 ISS)) as shown in Figure 2. Calling ”make” will generate the “pse.pse” which will be included by the OVP system on chip simulation.
Contains the source code for the OVP Model (compare with Figure 2). The example “platform.c” contains the instances of one ARM instruction set simulator that will execute the “OffisSimLinkDemo.elf” of the directory “EmbeddedApplication” and one instance of OffissimLink (“pse.pse” of previously mentioned directory). Calling ”make” will generate the executable “offisVP.exe”.
Calling “offisVP.exe” in the directory “OVP” will initialize the example platform by loading the ELF into the instruction set simulator, starting Matlab and opening the Simulink model. You will experience an “embedded SW for-loop” incrementing actuator values in Simulink. Simulink increments these actuator values after which they are read back by the embedded SW. This demonstrates both directions of data transmission.
OFFIS acknowledges the support by the 7th Framework Program ICT-4-5.1 for Personal Health Systems of the European Community (grant agreement: 248261) for the Nephron+ project for which the OfisSimLink peripheral was implemented. In the same context OFFIS has to recognize the willingness of Imperas to provide the OVPsim environment under a research license.