Changes between Version 7 and Version 8 of mapping_info

Timestamp:

Oct 26, 2014, 1:33:46 PM (10 years ago)

Author:

alain

Comment:

--

mapping_info

@@ -3 +3 @@
 [[PageOutline]]
 
-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. 
+The GIET_VM is a fully '''static operating system''' supporting clusterized, shared address space, many-cores architectures. These architecture 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. 
 
-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. 
+the GIET_VM bootloader map one or several multi-threaded user applications on the target architecture. 
+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 GIET_VM bootloader in the boot phase. 
 
-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.
+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 supports optional replication of critical objects such as kernel code, or page tables.
 
-To control this mapping, the system designer must define a mapping, as described below.
+To control the mapping, the system designer must provide a '''map.bin''' file containing a dedicated C binary data structure, that is loaded in memory by the bootloader.
+
+The next section describes this C binary structure. The following sections describe how  this binary file can be generated by the '''genmap''' tool from a python language description. Finally the genmap tool can generate a readable '''map.xml''' representation of the '''map.bin''' file.
 
 == __C mapping data structure__ ==
 
-A dedicated C binary data structure, is used by the GIET_VM bootloader to map one or several multi-threaded user applications on a generic, shared address space multi-processors, multi-clusters architecture. The next section describes how this this C binary structure can be generated by the ''genmap'' tool from a source description using the PYTHON language. We describe in this section this C structure.
-
 The C mapping data structure contains the following informations:
 
- 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. 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.
+ 1.  It contains a description of the target, clusterized, hardware architecture, with the following constraints: Processor cores are MIP32. 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. 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.
 
  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).