Changes between Version 11 and Version 12 of mapping_info

Timestamp:

Oct 27, 2014, 5:41:10 PM (10 years ago)

Author:

alain

Comment:

--

mapping_info

@@ -8 +8 @@
 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 supports replication of critical objects such as kernel code, or page tables.
-
-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 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 replication of (read-only) critical objects such as kernel code, user code, or page tables (the page tables are statically initialised in the boot phase, and are not modified anymore in the execution phase).
+
+To define 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.
@@ -115 +115 @@
 The supported ISR types are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file.
 
-== __Python global vsegs description__ ==
+== __Python kernel mapping__ ==
 
 The mapping of the GIET_VM vsegs must be defined in the ''arch.py'' file.
@@ -126 +126 @@
 || size          || segment size (bytes ||
 || mode        || access rights (CXWU) ||
-|| vtype        || software object type  ||
+|| vtype        || vseg type  ||
 || x              || destination cluster X coordinate ||
 || y              || destination cluster Y coordinate ||
@@ -134 +134 @@
 || align        || alignment constraint if required (default = 0) ||
 || local        || only mapped in local page table if true (default = False) ||
-|| big          || to be mapped in one or several big pages (2 Mbytes) || 
+|| big          || to be mapped in big pages (default = False) || 
 
 The supported values for the ''mode'' argument, and for the ''vtype'' arguments are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file.
@@ -151 +151 @@
 
 There is six types of vsegs for the GIET_VM kernel, but some vsegs are replicated in all clusters, to improve locality and minimize contention, as explained below:
- * The '''seg_kernel_ptab_x_y''' vseg has type PTAB. It contains the page tables for all vspaces (one page table per vspace). There is one such vseg in each cluster
-(one set of page tables per cluster). Each vseg is mapped in one big physical page. 
- * The '''seg_kernel_code''' & '''seg_kernel_init''' have type ELF. They contain the kernel code. These two vsegs must be mapped in one big physical page. They are  replicated in each cluster, to improve locality and minimize contention. The ''local'' attribute must be set, because the same virtual address will be mapped on different physical address depending on the cluster.   
+ * The '''seg_kernel_ptab_x_y''' vseg has type PTAB. It contains the page tables for all vspaces (one page table per vspace). There is one such vseg in each cluster (one set of page tables per cluster). Each PTAB vseg is mapped in one big physical page. 
+ * The '''seg_kernel_code''' & '''seg_kernel_init''' have type ELF. They contain the kernel code. These two vsegs must be mapped in one big physical page. They are  replicated in each cluster. The ''local'' attribute must be set, because the same virtual address will be mapped on different physical address depending on the cluster.   
  * The  '''seg_kernel_data''' & '''seg_kernel_uncdata''' have type ELF. They contain the kernel global data (cacheable, or non cacheable). They are not replicated, and must be mapped in cluster[0][0]. 
  * The '''seg_kernel_sched_x_y''' vseg has type SCHED. It contains the processor schedulers (one scheduler per processor). There is one such vseg in each cluster, and it must be mapped on small pages (two small pages per scheduler).
@@ -159 +158 @@
 === Peripheral vsegs ===
 
-As a global vseg can be mapped (replicated) in more than one cluster, the local argumentpage tables can be r, the ''local'' argument
-
-
-== __Python application description__ ==
+A global vseg must be defined for each addressable peripheral. 
+As a general rule, we use big physical page(s) for each external peripheral, and one small physical page for each replicated peripheral.
+
+== __Python user application mapping__ ==
+
+The mapping of a given application  must be defined in the ''application.py'' file.
+
+A vspace, containing a variable number of tasks, and a variable number of vsegs, must be defined for each application.
+
+There is several types of user vseg  
+ * The '''code''' vseg can be optionally replicated in all clusters. 
+ * The '''data''' vseg is not replicated. It must contain the ''start_vector'' defining the entry points of the application tasks.
+ * It must exist as many '''stack'''' vseg as the number of tasks. 
+ * One or several '''heap''' vseg(s), can be used by the malloc user library.
+ * One or several '''mwmr''' vseg(s)
+ 
+=== create the vspace ===
+
+The '''mapping.addvspace( )''' construct define a vspace. It has the following arguments:
+|| name        || vspace name == application name  ||
+|| startname || name of              || 
+
+===  vseg mapping ===
+
+The '''mapping.addVseg( )''' construct define the mapping of a vseg in the vspace. It has the following arguments:
+|| vspace     || vspace containing the vseg ||
+|| name       || vseg name ||
+|| vbase       || virtual base address ||
+|| size         || vseg size (bytes) ||
+|| mode      || access rights (CXWU) ||
+|| vtype       || vseg type ||
+|| x              || destination cluster X coordinate ||
+|| y              || destination cluster Y coordinate ||
+|| pseg        || destination pseg name ||
+|| binpath    || pathname for binary file if required (default = ' ') ||
+|| align        || alignment constraint if required (default = 0) ||
+|| local        || only mapped in local page table if true (default = False) ||
+|| big          || to be mapped in big pages (default = False) || 
+
+The supported values for the ''mode'' argument, and for the ''vtype'' arguments are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file.
+The ''x'', ''y'', and ''pseg'' arguments define actually the mapping.
+
+=== task mapping ===
+
+The '''mapping.addVseg( )''' construct  define the mapping of  a task in the vspace. It has the following arguments:
+|| vspace       || vspace containing the task ||
+|| name         || task name (unique in vspace) ||
+|| trdid          || thread index (unique in vspace] ||
+|| x                || destination cluster X coordinate ||
+|| y                || destination cluster Y coordinate ||
+|| lpid            || destination processor local index ||
+|| stackname || name of vseg containing stack ||
+|| heapname  || name of vseg containing heap ||
+|| startid        || index in start vector (defining the task entry point virtual address) ||
+
+The ''x'', ''y'', ''lpid'' arguments define actually the task placement.
+
+
+
+