GIET-VM documentation

The GIET_VM is a fully static operating system for shared address space, many-cores architectures. These architectures are generally NUMA (Non Uniform memory Acces), because the memory is logically shared, but physically distributed, and the main goal of the GIET_VM is to address these NUMA issues.

The GIET-VM assumes that the hardware architecture is structured as a 2D mesh of clusters. There is one physical memory bank, and several processor cores per cluster. Each processor is identified by a composite index [x,y,p] where x, y are the cluster coordinates, and p is the local processor index.

It is written for the MIPS32 processor. The virtual adresses are on 32 bits and use the (unsigned int) type, but the physicals addresses can have up to 40 bits, and use the (unsigned long long) type.

The GIET_VM supports a paged virtual memory, with two types of pages BPP (Big Physical Pages: 2 Mbytes), and SPP (Small Physical Pages: 4 Kbytes). The physical memory allocation is fully static, and all page tables (one page table per virtual space) are completely build and initialized in the boot phase. There is no page fault, and no swap on disk in the GIET_VM.

The GIET_VM supports parallel multi-tasks user application. A GIET_VM user application is similar to a POSIX process: one virtual space per application. A task is similar to a Posix thread: all tasks in a given application share the same virtual space. Any task can be allocated to any processor, but the allocation is fully static : no task migration. Therefore, there is one private scheduler for each processor.

The target architecture is generic, and the parameter values (such as the number of clusters, or the number of cores per cluster) are defined in the hard_config.h file. The GIET-VM itself has configuration parameters that are defined in the giet_config.h​ file.

A) Mapping

Both the target hardware architecture and the mapping directives (placement of software tasks on the physical processors / placement of the software objects on the physical memory banks) must be described in a python script. This section describes the Python constructs used to describe the mapping. This python script generates the map.bin C binary file, that is used by the boot-loader to initialise the system.

B) Boot-loader

The boot-loader code is loaded in the physical memory bank of cluster(0,0) by the generic reset code (hard-coded in the external ROM). The boot-loader load the map.bin file, build the page tables as specified in the mapping (one page table per virtual space), activates the MMU for all processors, initializes the distributed schedulers (one scheduler per processor), initializes the external (non replicated) peripherals, and load the kernel code, as well as the user application(s) code. When this is done, each processor jumps to the GIET_VM kernel_init() function that completes the kernel initialisation.

C) Kernel Initialisation

D) Boot & Kernel common functions

Here are presented the utility functions that can be used by both the bootloader (in the boot phase), and by the kernel (in the execution phase).

E) Kernel functions

F) System calls

G) User level libraries

B) Peripherals Drivers