Altreonic has developed a software tool called VirtuosoNext which provides fine-grain task level space partitioning. This allows protection of individual tasks from each other, i.e. preventing one task from corrupting the memory of another. Such protection can be crucial for the development of high-reliability systems that must be kept running even if one task becomes corrupted.
The scheme has a small memory overhead while keeping the real-time scheduling support of a traditional RTOS (real-time operating system).
VirtuosoNext is based on Altreonic’s formally developed and network-centric OpenComRTOS, allowing an almost seamless transition from existing OpenComRTOS 1.6 projects. Like its predecessor, VirtuosoNext supports the Virtual Single Processor (VSP) programming model whereby the RTOS abstracts the underlying distributed and heterogeneous processor hardware topology from the developer.
This allows the developer to concentrate on the application logic without having to worry about the communication between the different processing nodes in the system. Furthermore, this model enables the development of an application first on a single processing node and then distribution of the application onto multiple processing nodes, without modifying the application source code.
VirtuosoNext retains the static memory allocation at compile time that OpenComRTOS 1.6 uses. Static memory allocation by default avoids running out of memory resources during runtime by avoiding the dynamic allocation of memory. This is inherently safer than a dynamic memory allocation programming style and permits the linker to check at build time whether or not the application will fit in the available memory resources.
With VirtuosoNext, the application is split explicitly between a trusted and a non-trusted zone. The trusted zone contains the qualified kernel task and the driver layers. The non-trusted zone contains the application tasks that can use the services provided by the trusted zone. In this case the kernel task can be fully trusted as it underwent a qualification process.
Fine-grain task level space partitioning is advantageous compared to process level space partitioning since it allows a much finer level of partitioning without jeopardising the real-time capability, an issue that traditional hypervisor type approaches also have.
In process level space partitioning, the data of individual threads of a process are shared, which means they can corrupt each other’s data. This is not the case when using the space partitioning support of VirtuosoNext, whereby each task runs in user mode and is only permitted to access its own memory (allocated at compile time), as well as explicitly shared memory in the form of global variables. This also prevents direct access to the underlying hardware for which the application task can call the trusted services of the underlying RTOS kernel and its driver layer. Because VirtuosoNext drivers are implemented as tasks, the user can also develop them in supervisor mode.
The fine-grain space partitioning implementation of VirtuosoNext is lightweight both in code size and in runtime impact. The code size of OpenComRTOS 1.6 (used as a reference) and the VirtuosoNext implementation was compared by building the same application using all available services.
For the ARM Cortex-M3 platform (TI-LM3S6965 SoC) the code size increased by 360 Bytes to 19060 Bytes, while for the ARM Cortex-A9 platform (TI-OMAP4460) the code size increased by 6700 Bytes to 26932 Bytes. The larger increase is due to the more complex configuration needed for the MMU (Memory Management Unit) of the Cortex-A9 compared to the MPU (Memory Protection Unit) used by the Cortex-M3.
Space partitioning also affects runtime performance because the context of a task now also includes the information about the memory regions it is allowed to access. This becomes visible when comparing the time the system takes to perform a semaphore loop (two tasks, two semaphore hubs with one loop requiring eight context switches). For the Cortex-M3 (@50 MHz) the execution time per loop increased from 54,6 s to 58,9 s and for the Cortex-A9 (@700 MHz) the time increased from 11,59 s to 14,89 s.
In addition to fast context switching, an RTOS must be able to react predictably and with very low latency to external events – so called interrupts. In the case of VirtuosoNext and OpenComRTOS two interrupt latencies are of interest: the first one is the interrupt to ISR (Interrupt Service Routine) latency, and the second is the interrupt to task latency.
For the Cortex-M3 (@50 MHz) the minimal interrupt to ISR latency remained at 780 ns and the interrupt to task latency increased from 16 s to 17 s. The impact on the Cortex-A9 (@700 MHz) is that the minimal interrupt to ISR latency increased from 100 ns to 138 ns and the interrupt to task latency from 994 ns to 1726 ns.
VirtuosoNext uses the same powerful tools for system development and diagnostics as OpenComRTOS: the Visual Designer modelling environment and the Event Tracer tool. As a matter of fact these tools were not adjusted to support VirtuosoNext, but the build process was extended for the Cortex-M3 to ensure that the linker scripts conform to the alignment requirements imposed by this processor’s MPU (similarly to other Cortex-M and -R processors). This ensures that the user can build a fine-grain space partitioned system with the push of a button while being able to use both RTOS simultaneously in their system.
VirtuosoNext with fine-grain space partitioning is available on the Cortex-M3 (utilising the MPU) and on Cortex-A9 on which the MMU is utilised. It can be made available on other platforms such as ARM Cortex-M4F, ARM Cortex-R4, PowerPC e600 and Synopsys ARC600.
For more information contact Eric Verhulst, Altreonic, [email protected], www.altreonic.com
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version