Introduction to GeMRTOS system architecture #
In the GeMRTOS system architecture, a set of N processors shares a common memory and M input/output devices through a common bus. FIG. 2 shows a layout of the GeMRTOS controller interconnection in a multiprocessor architecture. The GeMRTOS controller receives device interrupt requests (DIRQs) from input/output peripheral devices. The GeMRTOS controller sends processor interrupt requests (PIRQs) to the system processors. The system bus allows the processors to share the system memory. Each processor has a unique internal identification register CPUID.

The GeMRTOS controller #
The controller is what makes GeMRTOS a natively multiprocessor system rather than a uniprocessor kernel later adapted to several processors. It is a hardware component synthesised into the FPGA alongside the processors, and it sits between the peripherals and the processors: device interrupt requests arrive at the controller, and the controller decides which processor to interrupt.
That decision is informed by software. On every dispatch, the kernel writes into the controller which processor is currently executing the least urgent work. Incoming external interrupts and expiring timed events are then targeted at the processor that is cheapest to preempt. Event routing is therefore a hardware decision taken with current scheduling knowledge, without any processor polling for work.
The controller also provides the system mutex that serialises kernel execution across processors, and the timing base for delays and deadlines. Because events are delivered when they occur, GeMRTOS is timer-tickless: there is no periodic tick interrupt waking processors to discover that nothing has happened. This event-driven organisation is the mechanism behind the system’s timing behaviour.
Processors #
GeMRTOS targets the Nios V soft processor, which is the current path for all present work. Nios II remains supported as a legacy route for existing designs. The same kernel C sources build for both; the processor-specific part is confined to the context-switch code and the hardware abstraction layer.
(Nios is a trademark of Altera Corporation or its subsidiaries.)
Integration with the Altera design flow #
GeMRTOS is delivered as a Platform Designer component. You add it to a system the same way you add any other IP, connect it to the processors and to the interrupt sources, and generate. There is no separate build system to adopt and no departure from the standard Quartus® Prime flow: GeMRTOS is designed to be integrated into Altera FPGA devices using the tools you already use.
The number of processors is a parameter of the system rather than a property of the operating system. Adding a processor is a Platform Designer change, not a kernel change.
Software layers #
The software is organised in strictly downward-flowing layers, so that application code never reaches hardware directly:
- Application — your tasks.
- Public API — the gu_ functions: tasks, semaphores, message queues, triggers, scheduling lists.
- Kernel services and kernel core — scheduling, synchronisation, inter-process communication, timing.
- Hardware abstraction layer — the only code that touches processor and controller registers.
One consequence matters for portability: a single kernel implementation serves every supported environment. Adding a platform does not fork the kernel.
Evaluating without hardware #
The same kernel sources also build for a Windows simulation layer, which reproduces the controller’s observable behaviour on a host PC. The complete example catalogue runs there, so the programming model, the scheduling behaviour and the API can be explored before an FPGA board is on your desk. The examples are delivered both on development boards and in this simulation layer.
Where to go next #
The scheduling model is the part of the architecture with the most direct effect on how you structure an application. See Hybrid Partition Scheduling in GeMRTOS, which explains how partitioned, global and exclusion-limited scheduling are all expressed through one mechanism.
