Changes between Version 39 and Version 40 of mapping_info

Timestamp:

Sep 26, 2015, 10:38:10 AM (9 years ago)

Author:

alain

Comment:

--

mapping_info

@@ -23 +23 @@
  * Most peripherals are ''external'' and  localized in one specific I/O cluster. 
  * A small number of peripherals (such as the XCU interrupt controller) are ''internal'' and replicated in each cluster containing processors.
- * The physical address 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 MSB fields (up to 4 bits for each field) define the cluster coordinates.
+ * The 40 bits physical address is the concatenation of 3 fields: the LSB field (32 bits) define a 4 Gbits physical address space inside a single cluster. The [X,Y] MSB fields (4 bits for each field) define the cluster coordinates.
 
 2. It contains a description of the GIET_VM kernel software objects (called virtual segments or ''vsegs''):
  * The kernel code is replicated in all clusters. Each copy is a ''vseg''. 
- * There is one page table for each user application, and this page table is replicated in each cluster. Each copy is a ''vseg''. 
+ * There is one page table for each user application. All page tables are packed in one single ''vseg'', and this ''vseg'' is
+replicated in each cluster. 
  * The kernel heap is distributed in all clusters. Each heap section is a ''vseg''.
  * Finally there is a specific ''vseg'' for each peripheral (both internal and external), containing the peripheral addressable registers. 
  All these kernel ''vsegs'' being accessed by all user applications must be defined in all virtual spaces, and are mapped in all page tables. They are called ''global vsegs''. 
 
-3. It  contains a description of the user application(s) 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. The number of tasks can depend on the target architecture. Each task must be statically placed on a given processor (p) in a given cluster(x,y). Moreover, each application defines a variable number of ''vsegs'':
+3. It  contains a description of the user application(s) 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. The user threads respect the POSIX API.The number of threads can depend on the target architecture. Each thread must be statically placed on a given processor (x,y,p). Moreover, each application defines a variable number of ''vsegs'':
  * The application code can be defined as a single ''vseg'', in a single cluster. It can also be replicated in all clusters, with one ''vseg''  per cluster.  
- * There is one stack for each application task. There is one ''vseg'' per stack, and each stack ''vseg'' must be placed in a specific cluster(x,y). 
+ * There is one stack per thread, and each stack ''vseg'' must be placed in a specific cluster(x,y). 
  * The data ''vseg'' contains the global (shared) variables. It is not replicated, and must be placed in a single cluster.
  * The user heap can be physically distributed on all clusters and it can exist one  heap ''vseg'' per cluster.
@@ -40 +41 @@
 == __C mapping data structure__ ==
 
-The C binary mapping data structure is defined in the [source:soft/giet_vm/giet_xml/mapping_info.h mapping_info.h] file, and is organised as the concatenation of a fixed size header, and 8 variable size arrays:
+The C binary structures used by the boot code are defined in the [source:soft/giet_vm/giet_xml/mapping_info.h mapping_info.h] file, and is organised as the concatenation of a fixed size header, and 8 variable size arrays:
 
 || mapping_cluster_t    || a cluster                 || contains psegs, processors, peripherals and coprocessors ||
@@ -51 +52 @@
 || mapping_periph_t    || a peripheral            || associated to a specific pseg  ||
 
-The ''map.bin'' file must be stored on disk and will be loaded by the GIET_VM bootloader in the ''seg_boot_mapping'' memory segment. 
+The ''map.bin'' file is automatically build by the ''genmap'' tool from the python scripts. It must be stored on disk in the file system root directory and will be loaded by the GIET_VM bootloader in the ''seg_boot_mapping'' memory segment. 
 
 == __Python mapping description__ ==