| | 109 | [[BR]] |
| | 110 | || '''Task 3.a''' : Multi-constrained centralized remapping scenario, Task manager : '''LIP6''', Partners : '''LIP6''', '''LIRMM''', '''LETI'''. In this approach, the information contained in the AIM-DB of WP2 is considered globally. Once the diagnosis has been performed, and the actions to be undertaken (skipping faulty parts in the remapping process, migrating threads to lower temperature on a region of the chip, etc…) clearly identified, a dedicated master processor on the MP2SoC executes the remapping algorithm, taking into account one AIM (single constrained, faulty parts) or several (multi-constrained) AIMs (faulty parts AND temperature AND processor workload, for instance). The remapping is actually composed of two steps: the remapping step that takes as inputs the application graph and the considered AIMs, and assigns hardware resources to threads, and the application relinking/reloading step that generates a new binary executable, appropriate global/local routing tables, and reloading orders from the collection of object files (thread object files and operating system object files) representing the running application. This way, the MP2SoC is able to self-adapt to a new application firmware. |
| | 111 | || T0+12 → T0+36|| |
| | 112 | || Status : '''not achieved yet'''|| |
| | 113 | |
| | 114 | [[BR]] |
| | 115 | || '''Task 3.b''' : Multi-constrained distributed remapping scenario, Task manager : '''LIRMM''', Partners : '''LIRMM''', '''LETI'''. This scenario is based on a distributed remapping strategy where each processing resource in the MP2SoC performs all three phases of the self-adaptation scheme in a continuous manner. This scenario therefore triggers remapping orders asynchronously (when a local Boolean condition becomes true for instance) with respect to the other units or clusters which also undergo the same process. Each of these operates according to one of the following principles: 1) local-only AIM database drives remapping decisions. Since remapping orders are issued locally, a lot of effort has to be put into researching adequate remapping policies; specifically because we here consider both migration and replication operations for this phase. 2) global, periodically broadcasted instant map system view guide the remapping process. In this specific case we assume that this global information is potentially outdated. Here again we do consider both migration and replication. 3) An intermediate solution between centralized and fully distributed will also be explored; based on a globally issued placement some regions will undergo locally decided remapping in order to perform local placement refinements For this specific solution, only task migrations are considered. |
| | 116 | || T0+12 → T0+36|| |
| | 117 | || Status : '''not achieved yet'''|| |
| | 118 | |
| | 119 | [[BR]] |
| | 120 | || '''Task 3.c''' : Mutualized System-level Case studies, Task manager : '''LIRMM''''''''', Partners : '''ALL'''. In order to fairly benchmark the proposed remapping solutions, both centralized and distributed remapping scenarios will be validated on four already existing multi-threaded applications. Applications range from a simple MJPEG application to a complete fourth generation mobile telecommunication system, 3GPP-LTE (Long Term Evolution). H264 and MP3 decoding applications will also be studied. This will help in clearly quantifying the benefits of the proposed approaches as this application is representative of the real applications that MP2SoC will soon have to run. More precisely, the partners will setup a result table with 2 lines (1/centralized, 2/distributed) and four columns (MJPEG, MP3, H264, 3GPP-LTE) and identify scientifically for each table cell the pros and cons of the remapping scenario. |
| | 121 | || T0+18 → T0+36|| |
| | 122 | || Status : '''not achieved yet'''|| |
