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 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