Changes between Version 33 and Version 34 of mapping_info
- Timestamp:
- Mar 8, 2015, 2:58:21 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
mapping_info
v33 v34 4 4 5 5 The GIET_VM bootloader loads the GIET_VM kernel and the user application(s) on the target architecture. 6 All user applications s oftware objects, the kernel code and the critical kernel structures (such as the page tables or theprocessors schedulers) are statically build by the GIET_VM bootloader, as specified by the mapping directives.6 All user applications segments (code, data, stack and heap) the kernel code and the critical kernel structures (page tables or processors schedulers) are statically build by the GIET_VM bootloader, as specified by the mapping directives. 7 7 8 8 The 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. … … 10 10 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. 11 11 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 Python scripts. 13 The '''genmap''' tool generates also a readable '''map.xml''' representation of the '''map.bin''' file. 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 Python scripts. The '''genmap''' tool generates also a readable '''map.xml''' representation of the '''map.bin''' file. 14 13 15 14 == __Mapping content__ == … … 17 16 The mapping contains the following informations: 18 17 19 1. It contains a description of the target, clusterized, hardware architecture, with the following constraints: 18 1. It contains a description of the target hardware architecture, with the following constraints: 19 * All hardware components respect the VCI communication protocol. 20 20 * All processor cores are identical (MIPS32). 21 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 parameter s.variable.22 * The number of processors per cluster is defined by the NPROCS parameter. 23 23 * The number of physical memory banks is variable (typically one physical memory bank per cluster). 24 24 * Most peripherals are ''external'' and localized in one specific I/O cluster. … … 33 33 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''. 34 34 35 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 parallel tasks sharing the same address space depends on the target architecture, and 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'':36 * The application code can be defined as a single ''vseg'', placedin a single cluster. It can also be replicated in all clusters, with one ''vseg'' per cluster.35 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'': 36 * 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. 37 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 38 * The data ''vseg'' contains the global (shared) variables. It is not replicated, and must be placed in a single cluster. … … 41 41 == __C mapping data structure__ == 42 42 43 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 10variable size arrays:43 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: 44 44 45 45 || mapping_cluster_t || a cluster || contains psegs, processors, peripherals and coprocessors || … … 50 50 || mapping_proc_t || a processor || identified by a triple index (x,y,lpid) || 51 51 || mapping_irq_t || a source interrupt || define the ISR to be executed || 52 || mapping_coproc_t || a coprocessor || contains several cp_ports ||53 || mapping_cp_port_t || a coprocessor port || define input/output direction ||54 52 || mapping_periph_t || a peripheral || associated to a specific pseg || 55 53 56 The ''map.bin'' file must be stored on disk and will be loaded in memory by the GIET_VM bootloader in the ''seg_boot_mapping''segment.54 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. 57 55 58 56 == __Python mapping description__ == 59 57 60 A specific mapping requires at leasttwo python files:58 A mapping requires two python files: 61 59 * The '''arch.py''' file is attached to a given hardware architecture. It describes both the (possibly generic) hardware architecture, and the mapping of the kernel software objects on this hardware architecture. 62 * The '''appli.py''' file is attached to a given user application. It describes the application structure (tasks and communication channels), and the mapping of the application tasks and software objects on the architecture.60 * The '''appli.py''' file is attached to a given user application. It describes the application structure (tasks and vsegs), and the mapping of tasks and vsegs on the architecture. 63 61 64 62 The various Python Classes used by these these files are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file. … … 97 95 || '''lpid''' || processor local index || 98 96 99 The global processor index is : ( ( x << y_width ) + y ) << p_width ) + lpid97 The global processor index (stored in CP0_PROCID register) is : ( ( x << y_width ) + y ) << p_width ) + lpid 100 98 101 99 === 3. Physical memory bank === … … 117 115 || '''subtype''' || Peripheral subtype || 118 116 || '''channels''' || number of channels for multi-channels peripherals || 119 || '''arg''' || optionnal argument depending on peripheral type || 120 121 The target cluster coordinates (x,y) are implicitely defined by the base address MSB bits. 117 || '''arg0''' || optionnal argument depending on peripheral type || 118 || '''arg1''' || optionnal argument depending on peripheral type || 119 || '''arg2''' || optionnal argument depending on peripheral type || 120 || '''arg3''' || optionnal argument depending on peripheral type || 121 122 The target cluster coordinates (x,y) are implicitely defined by the physical base address MSB bits. 122 123 The supported peripheral types and subtypes are defined in the [source:soft/giet_vm/giet_python/mapping.py mapping.py] file. 123 The optionnal argument has the following semantic: 124 * for XCU : max number of WTI = max number of HWI = max number of PTI 125 * for FBF : number of lines = number of pixels per line 124 Hardware coprocessors using the MWMR_DMA controller to access memory are described as peripherals. They must be defined with the MWR ''ptype'' argument, and the ''subtype'' argument defines the coprocessor type. 125 126 The following peripheral require specific arguments with the following semantic: 127 || || Frame Buffer || Interrupt controller || Generic DMA Controller || 128 || ptype || FBF || XCU || MWR || 129 || arg0 || number of pixels per line || Number of HWI inputs || number of TO_COPROC ports || 130 || arg1 || number of lines || Number of WTI inputs || number of FRPM_COPROC ports || 131 || arg2 || unused || Number of PTI inputs || number of CONFIG registers || 132 || arg3 || unused || NUMBER of outputs || number of STATUS registers || 126 133 127 134 === 5. Interrupt line ===