Changes between Version 24 and Version 25 of arch_info
- Timestamp:
- Jun 20, 2018, 6:13:12 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
arch_info
v24 v25 3 3 [[PageOutline]] 4 4 5 ALMOS-MKH has been designed to support clustered manycore architectures. It can be 32 bits cores (such as the MIPS32 based TSAR architecture), or 64 bits cores (such as the multi-cores Intel/AMD architectures). Each cluster containing at least one core, one physical memory bank, and an interrupt controller unitwill host one kernel instance.5 ALMOS-MKH has been designed to support clustered manycore architectures. It can be 32 bits cores (such as the MIPS32 based TSAR architecture), or 64 bits cores (such as the multi-cores Intel/AMD architectures). Each cluster containing enough hardware resources to execute kernel code ( i.e. one core, one physical memory bank, and an interrupt controller unit) will host one kernel instance. 6 6 7 7 All relevant parameters describing the clustered multi-core architecture must be defined in the binary '''arch_info.bin''' file. 8 This binary file is exploited by the ALMOS-MKH boot-loader to configure ALMOS-MK. It can be generated by a specific '''arch_info.py''' python scrip, for each target architecture.8 This binary file is exploited by the ALMOS-MKH boot-loader to configure ALMOS-MK. For each target architecture, there is a specific '''arch_info.py''' python script, used to generate this '''arch_info.bin''' file. 9 9 10 10 == __1) Cluster and cores identification__ == … … 12 12 === 1.1) Cluster identification === 13 13 14 To identify a cluster in the clustered architecture, ALMOS-MKH uses a nunique cluster identifier '''cxy'''. ALMOS-MK does not make any15 assumption on the clusters topology, but makes the assumption that the '''cxy''' binary value can be directly concatenated to the local physical address (address inside a cluster) to build a global physical address. Warning: The cluster identifier '''cxy''' is NOT a continuous index, and cannot be used to index a clusterarray.14 To identify a cluster in the clustered architecture, ALMOS-MKH uses a unique cluster identifier '''cxy'''. ALMOS-MK does not make any 15 assumption on the clusters topology, but makes the assumption that the '''cxy''' binary value can be directly concatenated to the local physical address (address inside a cluster) to build a global physical address. Warning: The cluster identifier '''cxy''' is NOT a continuous index, and therefore , it cannot be used to index a clusters array. 16 16 17 The size of the local physical address space (inside a cluster) is defined by a global parameter, that is the number of bits in a local physical address. The value of this parameter is 32 in architectures using 32 bits cores, but it can be larger in architectures using 64 bits cores. A physical address is coded on 64 bitsin ALMOS-MKH.17 The size of the local physical address space (inside a cluster) is defined by a global configuration parameter in the '''kernel_config.h''' file, that is the number of bits in a local physical address. The value of this parameter is 32 in architectures using 32 bits cores, but it can be larger in architectures using 64 bits cores. A physical address is coded on a 64 bits integer in ALMOS-MKH. 18 18 19 Note : In architectures where the clusters are organized as a 2D mesh topology, is is generally possible to derive the [x,y] cluster coordinates from the '''cxy''' cluster identifier, and ALMOS-MK can use it to optimize placement and improve locality, but this optimisation is NOT mandatory, and ALMOS-MK supports architectures where the set of cluster is simply a linear vector of clusters.19 Note : In architectures where the clusters are organized as a 2D mesh topology, is is generally possible to derive the [x,y] cluster coordinates from the '''cxy''' cluster identifier, and ALMOS-MK can use it to optimize placement and improve locality, but this optimisation is NOT mandatory, and ALMOS-MKH supports architectures where the set of cluster is simply a linear vector of clusters. 20 20 21 21 === 1.2) Core identification === 22 22 23 ALMOS-MK makes the assumption that each physical core contains an hardware addressable register defining a nunique global identifier (called '''gid''') with the only constraint that two different cores have two different '''gid'''.23 ALMOS-MK makes the assumption that each physical core contains an hardware addressable register defining a unique global identifier (called '''gid''') with the only constraint that two different cores have two different '''gid'''. 24 24 25 To identify a specific core in the clustered architecture, ALMOS-MK does not use directly this physical '''gid''', but uses a composite index '''[cxy,lid]''', where '''cxy''' is the cluster identifier, and '''lid''' is a local core index. This '''lid''' index is a continuous index in [0,N-1], where N can depend on the cluster, but cannot be larger than the global parameter CONFIG_MAX_CORE_PER_CLUSTER_NR.25 To identify a specific core in the clustered architecture, ALMOS-MK does not use directly this physical '''gid''', but uses a composite index '''[cxy,lid]''', where '''cxy''' is the cluster identifier, and '''lid''' is a local core index. This '''lid''' index is a continuous index in [0,N-1], where N can depends on the cluster, but cannot be larger than the global parameter CONFIG_MAX_CORE_PER_CLUSTER_NR. 26 26 27 27 The association of a composite index '''[cx,lid]''' to a global physical identifier '''gid''', is defined in the '''arch_info.bin''' file. … … 40 40 * The number of addressable peripherals per cluster is variable. 41 41 * The size of the physical memory bank per cluster is variable. 42 * Each cluster cover a fixed size segment in the physical address space.42 * Each cluster covers a fixed size segment in the physical address space. 43 43 44 === 2.2) the arch_info_t structure ===44 === 2.2) The arch_info_t structure === 45 45 46 The binary file '''arch_info.bin''' is a BLOB containing the binary form of the C arch_info_t structure.46 The binary file '''arch_info.bin''' is a BLOB defined in the '''arch_info.h''' file . 47 47 This structure has a three levels hierarchical organisation: 48 48 * the architecture contains a variable number of clusters. … … 65 65 These Python classes are defined in the [source:soft/almos-work/tools/python/genarch.py genarch.py] file. 66 66 67 The target hardware architecture must be defined in the ''arch .py'' file , you must use the following constructors:67 The target hardware architecture must be defined in the ''arch_info.py'' file , you must use the following constructors: 68 68 69 === 3.1) architecture ===69 === 3.1) Architecture === 70 70 71 The Archi ( ) constructor buildan ''archi'' object and defines the target architecture general parameters:71 The Archinfo( ) constructor builds an ''archi'' object and defines the target architecture general parameters: 72 72 73 73 || '''name''' || target architecture name || 74 74 || '''x_size''' || number of clusters in a row (for a 2D mesh) || 75 || '''y_size''' || number of clusters in a column (for a 2D mesh) || 75 || '''y_size''' || number of clusters in a column (for a 2D mesh) || 76 || '''cores_max''' || max number of cores per cluster || 77 || '''devices_max''' || max number of devices per cluster || 78 || '''paddr_width''' || number of bits in physical address || 76 79 || '''x_width''' || number of bits to encode X coordinate in CXY || 77 80 || '''y_width''' || number of bits to encode Y coordinate in CXY || 78 || '''cores_max''' || max number of cores per cluster ||79 || '''cluster_span''' || number of bits in local physical address ||80 81 || '''irq_per_proc''' || number of IRQ lines between XCU and one core || 81 || '''use_ramdisk''' || Boolean true if the architecture contains a RamDisk ||82 82 || '''io_cxy''' || io_cluster identifier || 83 || '''boot_cxy''' || boot_cluster identifier || 83 || '''boot_cxy''' || boot_cluster identifier || 84 || '''cache_line''' || number of bytes in cache line || 84 85 || '''reset_address''' || physical base address of the ROM containing the preloader code || 86 || '''p_width''' || number of bits to code the local core identifier || 85 87 86 88 === 3.2) Processor core === … … 91 93 || '''gid''' || core hardware identifier || 92 94 93 === 3.3) P hysical memory bank===95 === 3.3) Peripherals === 94 96 95 The '''archi.addRam( )''' construct adds one physical memory segment in a cluster. It has the following arguments: 96 || '''cxy''' || cluster identifier || 97 The '''archi.addDevice( )''' construct adds one peripheral in a cluster. ALMOS-MKH supports multi-channels peripherals. 98 This construct has the following arguments: 99 || '''ptype''' || Peripheral type || 97 100 || '''base''' || local physical base address || 98 101 || '''size''' || segment size (bytes) || 99 100 === 3.4) Peripherals ===101 102 The '''archi.addDevice( )''' construct adds one peripheral in a cluster. ALMOS-MK supports multi-channels peripherals.103 ALMOS-MK supports multi-channels peripherals.104 This construct has the following arguments:105 || '''cxy''' || cluster identifier ||106 || '''base''' || local physical base address ||107 || '''size''' || segment size (bytes) ||108 || '''ptype''' || Peripheral type ||109 102 || '''channels''' || number of channels for multi-channels peripherals || 110 103 || '''arg0''' || optional argument depending on peripheral type || … … 116 109 The supported peripheral types are defined in the [source:almos-work/tools/arch_info/arch_classes.py arch_classes.py] file. 117 110 118 The following peripheral components require specific arguments with the following semantic :111 The following peripheral components require specific arguments with the following semantic depending on the functionnal type: 119 112 || || Frame Buffer || Interrupt controller || Generic DMA Controller || 120 || ptype || FBF || XCU || MWR||121 || arg0 || number of pixels per line || Number of HWI inputs || number of TO_COPROC ports ||113 || ptype || FBF_*** || ICU_*** || DMA_*** || 114 || arg0 || number of pixels per line || Number of HWI inputs || number of TO_COPROC ports || 122 115 || arg1 || number of lines || Number of PTI inputs || number of FROM_COPROC ports || 123 116 || arg2 || unused || Number of WTI inputs || number of CONFIG registers || 124 117 || arg3 || unused || Number of IRQ outputs || number of STATUS registers || 125 118 126 Hardware coprocessors using the Generic DMA controller to access memory are described as peripherals. They must be defined with the MWR ''func_ptype'' argument, and the ''impl_type'' argument defines the coprocessor type. 127 128 === 3.5) Interrupt line === 119 === 3.4) Interrupt line === 129 120 130 121 The '''archi.addIrq()''' construct is used to describe the hardware interrupts routing from an output interrupt port in a physical peripheral, to an input interrupt port in an interrupt concentrator. This construct adds one input IRQ line to an XCU peripheral, or to a PIC peripheral. It has the following arguments: 131 || '''dst _dev''' || destination device (XCU or PIC) ||132 || ''' index'''|| input port index in destination device ||133 || '''src _dev'''|| source device ||122 || '''dstdev''' || destination device (XCU or PIC) || 123 || '''port''' || input port index in destination device || 124 || '''srcdev''' || source device || 134 125 || '''channel''' || source device channel (default value is 0) || 135 || '''is_rx''' || source device direction (default value is False) || 136 126 || '''is_rx''' || source device direction (default value is False) || 137 127 138 128 == __4) The boot_info_t structure__ == 139 129 140 The ALMOS-MKH boot-loader uses the information sfound in '''arch_info.bin''' to build one '''boot_info_t''' structure in each cluster. This generic '''boot_info_t''' structure is used by the kernel to build in each cluster its own representation of the hardware.130 The ALMOS-MKH boot-loader uses the information found in '''arch_info.bin''' to build one '''boot_info_t''' structure in each cluster. This generic '''boot_info_t''' structure is used by the kernel to build in each cluster its own representation of the hardware. 141 131 Therefore, the '''boot_info_t''' structure defines the generic (hardware independent) interface between the hardware specific boot-loader and the kernel. 142 132