Altreonic is proud to announce the first version of VirtuosoNext™ which provides fine-grain Task level space partitioning. This allows protecting individual Tasks from each other, i.e. preventing one Task from corrupting the memory of another Task. 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.
VirtuosoNext™ is based on Altreonic NV'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 allows to develop an application first on a single Processing Node and then distribute the application onto multiple Processing Nodes, without modifying the application source code.
VirtuosoNext™ retained 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 programing 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 now split explicitly between a trusted and a non-trusted zone. The trusted zone contains the qualified kernel Task and the driver layers. The untrusted 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 compared to process level space partitioning has the advantage that it allows a much finer level of partitioning without jeopardizing the real-time capability, an issue that also traditional hypervisor type approaches 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. As in 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 (compiled with Os). For the ARM-Cortex-M3 platform (TI-LM3S6965 SoC) the code size increased by 2908 bytes to 11564 bytes. For the ARM-Cortex-A9 platform (TI-OMAP4460) the code size increased by 6700 bytes to 21844 bytes. The larger increase is due to the more complex configuration needed for the MMU (Memory Management Unit) of the ARM-Cortex-A9 compared to the MPU (Memory Protection Unit) used by the ARM-Cortex-M3.
Space partitioning also affects runtime performance because the context of a Task now includes also 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 ARM-Cortex-M3 (@50MHz) the execution time per loop has increased from 54.6 μs to 58.9 μs (compiled at O3) and for the ARM-Cortex-A9 (@700MHz) the time increased from 11.59 μs to 14.89 μs (compiled at O3).
In addition to fast context switching a RTOS must also be able to react predictably and with very low latency to external events, so called Interrupts. In the case of VirtuososNext™ and OpenComRTOS™ we define two Interrupt Latencies of interest. The first one is the Interrupt to ISR (Interrupt Service Routine) Latency, the second is the Interrupt to Task Latency. For the ARM-Cortex-M3 (@50MHz) the minimal Interrupt to ISR Latency remained at 780 ns (compiled with Os) and the Interrupt to Task Latency increased from 16 μs to 17 μs (compiled with Os). The impact on the ARM-Cortex-A9 (@700MHz) is that the minimal Interrupt to ISR Latency increased from 100 ns to 138 ns (compiled with O3) and the Interrupt to Task Latency from 994 ns to 1726 ns (compiled with O3).
VirtuosoNext™ uses the same powerful tools for system development and diagnostics, as OpenComRTOS™: the Visual Designer modeling environment and the Event Tracer tool. As a matter of fact these tools were not adjusted to support VirtuosoNext™. However, we extended the build process for the ARM-Cortex-M3 to ensure that the linker scripts conform to the alignment requirements imposed by this processor's MPU (and other ARM-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 his system.
VirtuosoNext™ with fine-grain space partitioning is available on the ARM-Cortex-M3 (utilising the MPU) and on ARM-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 please do not hesitate to get in touch with us at:
Bernhard.Sputh (at) altreonic.com
Eric.Verhulst (at) altreonic.com