| 3 | [[PageOutline]] |
| 4 | |
| 5 | The GIET_VM is a fully '''static operating system''' supporting clusterized, shared address space, NUMA (Non Uniform memory Acces), many-cores architectures, contening MIPS32 processors. |
| 6 | |
| 7 | All software objects (user applications code and data, but also kernel code and critical kernel structures such as the page tables or the processors schedulers) are statically build and loaded from disk into physical memory by the bootloader in the boot phase. |
| 8 | |
| 9 | The main advantage of this static approach is to provide the system designed a full control on the placement of tasks on processors but also of the data (software objects) on the distributed physical memory banks. It allows optional replication of critical objects such as kernel code, or page tables. |
| 10 | |
| 11 | To control this mapping, the system designer must define a mapping, as described below. |
11 | | 1. It contains a description of the target, clusterized, hardware architecture, with the following constraints: The clusters are identified by the (x,y) coordinates in a 2D mesh topology. The number of clusters is variable (can be one). The number of processors per cluster is variable (can be one). The number of physical memory banks is variable (up to one physical memory bank per cluster. Most peripherals are ''external'' and localized in one specific I/O cluster. |
12 | | 2. It contains a description of the user applications to be launched on the platform. An user application is characterized by a a virtual address space, called a ''vspace''. The number of parallel ''tasks'' per application is variable (can be one). Multi-Writer/Multi-Reader communication channels between tasks are supported. Each vspace contains a variable number of virtual segments, called ''vsegs''. The number of vspace can be one. |
| 19 | 1. It contains a description of the target, clusterized, hardware architecture, with the following constraints: The clusters are organised in a 2D mesh topology, and the number of clusters is variable (can be one). The number of processors per cluster is variable (can be one). The number of physical memory banks is variable (up to one physical memory bank per cluster. Most peripherals are ''external'' and localized in one specific I/O cluster. |
| 20 | The physical address width is between 32 and 48 bits, and is the concatenation of 3 fields: the LSB field (32 bits) define a 4 Gbits physical address space inside a single cluster. The X and Y fields (up to 8 bits for each field) define the cluster coordinate. |
| 21 | |
| 22 | 2. It contains a description of the user applications to be launched on the platform. An user application is characterized by a a virtual address space, called a ''vspace''. An user application can be multi-threaded, and the number of parallel tasks sharing the same address space in a given application is variable (can be one). The GIET_VM provide a specific Multi-Writer/Multi-Reader communication middleware for send/receive inter-tasks communication. Each vspace contains a variable number of virtual segments, called ''vsegs''. The number of simultaneously mapped vspaces on a given architecture is variable (can be one). |
| 23 | |
32 | | * The '''arch.py''' file is attached to a given hardware architecture. It describes both the (possibly generic) hardware architectures, and the mapping of the kernel software objects on this architecture. |
33 | | * The '''appli.py''' file is attached to a given user application. It describes the both the application structure (tasks and communication channels), and the mapping of the application tasks and software objects on the architecture. |
| 44 | * The '''arch.py''' file is attached to a given hardware architecture. It describes both the (possibly generic) hardware architectures, and the mapping of the kernel software objects on this hardware architecture. |
| 45 | * The '''appli.py''' file is attached to a given user application. It describes both the application structure (tasks and communication channels), and the mapping of the application tasks and software objects on the architecture. |
45 | | || name || mapping name == architecture name || |
46 | | || x_size || number of clusters in a row of the 2D mesh || |
47 | | || y_size || number of clusters in a column of the 2D mesh || |
48 | | || nprocs || number of processors per cluster || |
49 | | || x_width || number of bits to encode X coordinate in paddr (default = 4) || |
50 | | || y_width || number of bits to encode Y coordinate in paddr (default = 4) || |
51 | | || p_width || number of bits to encode local processor index (default = 4) || |
52 | | || paddr_width || number of bits in physical address || |
53 | | || coherence || Boolean true if hardware cache coherence || |
54 | | irq_per_proc # number of IRQ lines between XCU and proc |
55 | | use_ramdisk # Boolean true if the architecture contains a RamDisk |
56 | | x_io # io_cluster X coordinate |
57 | | y_io # io_cluster Y coordinate |
58 | | peri_increment # peri_increment, |
59 | | ram_base # Physical memory bank base address in cluster [0,0] |
60 | | ram_size # ram_size ) |
| 57 | || name || mapping name == architecture name || |
| 58 | || x_size || number of clusters in a row of the 2D mesh || |
| 59 | || y_size || number of clusters in a column of the 2D mesh || |
| 60 | || nprocs || number of processors per cluster || |
| 61 | || x_width || number of bits to encode X coordinate in paddr || |
| 62 | || y_width || number of bits to encode Y coordinate in paddr || |
| 63 | || p_width || number of bits to encode local processor index || |
| 64 | || paddr_width || number of bits in physical address || |
| 65 | || coherence || Boolean true if hardware cache coherence || |
| 66 | || irq_per_proc || number of IRQ lines between XCU and one proc (GIET_VM use only one) || |
| 67 | || use_ramdisk || Boolean true if the architecture contains a RamDisk || |
| 68 | || x_io || io_cluster X coordinate || |
| 69 | || y_io || io_cluster Y coordinate || |
| 70 | || peri_increment || virtual address increment for peripherals replicated in all clusters || |
| 71 | || reset_address || physical base address of the ROM containing the preloader code || |
| 72 | || ram_base ||physical memory bank base address in cluster [0,0] || |
| 73 | || ram_size || physical memory bank size in one cluster (bytes) || |