Changes between Version 19 and Version 20 of mapping_info


Ignore:
Timestamp:
Feb 14, 2015, 10:32:57 PM (9 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • mapping_info

    v19 v20  
    33[[PageOutline]]
    44
    5 The GIET_VM bootloader map the kernel and one or several multi-threaded user applications on the target architecture.
    6 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.
    7 
    8 The main advantage of this static approach is to provide the system designer to place the tasks on the processors, but also to place 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 initialized in the boot phase, and are not modified anymore in the execution phase.
     5The GIET_VM bootloader loads the GIET_VM kernel and the user application(s) on the target architecture.
     6All user applications software objects, but also the kernel code and the critical kernel structures such as the page tables or the processors schedulers are statically build  by the GIET_VM bootloader, as specified by the mapping directives defined in various Python scripts.
     7
     8The main goal of this static approach is to allow the system designer to control the placement of the tasks on the processors, but also to control the placement of 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 initialized in the boot phase, and are not modified anymore in the execution phase.
    99
    1010To 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.
    1111
    12 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.
     12The next section describes this C binary structure. The following sections describe how  this binary file can be generated by the '''genmap''' tool from Python scripts.
     13The '''genmap''' tool generates also a readable '''map.xml''' representation of the '''map.bin''' file.
    1314
    1415== __C mapping data structure__ ==
    … …  
    1617The C mapping data structure contains the following informations:
    1718
    18  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.
    19 
    20  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).
    21 
    22  3. It contains the mapping directives: The tasks are statically allocated to processors. The various software objects (user and kernel code segments, tasks stacks, tasks heaps, communication channels, etc.) are called ''vobjs'', and are statically placed on the distributed physical memory banks (called ''psegs''),  using the page tables (one page table per vspace) that define the mapping of the vsegs on the psegs.
    23 
    24 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 11 variable size arrays:
    25 || mapping_cluster_t    || a cluster                 || contains psegs, processors, peripherals and coprocessors ||
    26 ||  mapping_pseg_t      || a physical segment ||                                                                                          || 
     19 1.  The mapping contains a description of the target, clusterized, hardware architecture, with the following constraints:
     20 * Processor cores are MIP32.
     21 * The clusters form a 2D mesh topology. The mesh size is defined by the (X_SIZE,Y_SIZE) parameters.
     22 * The number of processors per cluster is defined by the NPROCS parameters.variable.
     23 * The number of  physical memory banks is variable (typically one physical memory bank per cluster).
     24 * Most peripherals are ''external'' and  localized in one specific I/O cluster.
     25 * A small number of peripherals (such as the XCU interrupt controller) are ''internal'' and replicated in each cluster containing processors.
     26 * 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.
     27
     28 2. the mapping contains a description of the GIET_VM kernel software objects (called virtual segments or ''vsegs''):
     29 * The kernel code is replicated in all clusters. Each copy is a ''vseg''.
     30 * There is one page table for each user application, and this page table is replicated in each cluster. Each copy is a ''vseg''.
     31 * The kernel heap is distributed in all clusters. Each heap section is a ''vseg''.
     32 * Finally there is a specific ''vseg'' for each peripheral (both internal and external), containing the peripheral addressable registers.
     33All these vsegs being accessed by all user applications must be defined in all virtual spaces, and are mapped in all page tables. They are called ''globa' vsegs''.
     34
     35 3. The mapping  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). Each task must be statically placed on a processor P(x,y,p). Moreover, each application defines a variable number of ''vsegs'':
     36 * The application code can be defined as a single ''vseg'', placed in a single cluster. It can also be replicated in all clusters, with one ''vseg''  per cluster. 
     37 * 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).
     38 * The data ''vseg'' contains the global (shared) variables. It is not replicated, and must be placed in a single cluster.
     39 * The user heap can be physically distributed on all clusters and it can exist one  heap ''vseg'' per cluster.as many ''vsegs''.
     40
     41The 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 10 variable size arrays:
     42
     43||  mapping_cluster_t    || a cluster                 || contains psegs, processors, peripherals and coprocessors ||
     44||  mapping_pseg_t      || a physical segment ||  defined by a name, a base address ans a size (bytes)         || 
    2745||  mapping_vspace_t   || a virtual space        || contains several vsegs and several parallel tasks                ||
    28 ||  mapping_vseg_t      || a virtual segment    || contains one or several vobjs                                             ||     
    29 ||  mapping_vobj_t       || a software object    ||                                                                                          ||
    30 ||  mapping_task_t       || a task                      ||                                                                                         || 
    31 ||  mapping_proc_t       || a processor             ||                                                                                         ||
    32 ||  mapping_periph_t   ||  a peripheral            || can contain IRQ inputs (XCU or PIC)                                  ||
    33 ||  mapping_irq_t         || a source interrupt   ||                                                                                          ||
     46||  mapping_vseg_t      || a virtual segment    || contains one software object                                             ||     
     47||  mapping_task_t       || a task                      ||  must be statically associated to a processor                    || 
     48||  mapping_proc_t       || a processor             ||  identified by coordinates (x,y) and a local index (p)         ||
     49||  mapping_periph_t   ||  a peripheral            || can contain IRQ inputs (for XCU or PIC peripherals)           ||
     50||  mapping_irq_t         || a source interrupt   ||                                                                                       ||
    3451||  mapping_coproc_t   || a coprocessor          || contains several cp_ports                                                 ||
    3552||  mapping_cp_port_t  || a coprocessor port  ||                                                                                         ||