Changes between Version 21 and Version 22 of arch_info
- Timestamp:
- Apr 4, 2018, 9:39:38 AM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
arch_info
v21 v22 3 3 [[PageOutline]] 4 4 5 ALMOS-MK 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 unit will 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 at least 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-MK 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. It can be generated by a specific '''arch_info.py''' python scrip, for each target architecture. 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-MK uses an unique cluster identifier '''cxy'''. ALMOS-MK does not make any14 To identify a cluster in the clustered architecture, ALMOS-MKH uses an unique cluster identifier '''cxy'''. ALMOS-MK does not make any 15 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 cannot be used to index a cluster 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 ny physical address is coded on 64 bits in ALMOS-MK.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 bits in ALMOS-MKH. 18 18 19 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. … … 29 29 == __2) Hardware architecture description__ == 30 30 31 For ALMOS-MK , the target hardware architecture is described in the binary file '''arch_info.bin'''.32 This file is loaded from disk by the ALMOS-MK boot-loader.31 For ALMOS-MKH, the target hardware architecture is described in the binary file '''arch_info.bin'''. 32 This file is loaded from disk by the ALMOS-MKH boot-loader. 33 33 34 34 === 2.1) General assumptions === … … 138 138 == __4) The boot_info_t structure__ == 139 139 140 The ALMOS-MK boot-loader uses the informations 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 ALMOSkernel to build in each cluster its own representation of the hardware.140 The ALMOS-MKH boot-loader uses the informations 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 141 Therefore, the '''boot_info_t''' structure defines the generic (hardware independent) interface between the hardware specific boot-loader and the kernel. 142 142