Changes between Version 18 and Version 19 of projectstructure

Timestamp:

Jun 16, 2008, 4:37:03 PM (16 years ago)

Author:

fpecheux

Comment:

--

projectstructure

@@ -60 +60 @@
 || T0+12 → T0+24||
 || Status : '''not achieved yet'''|| 
+
 [[BR]]
 || '''Task  2.b''' :  Hard/Soft alert triggering, Task manager : '''LIP6''', Partners : '''ALL'''. This task is dedicated to the appropriate exploitation of the formatted events available in the tables of the DRET, filled by all the mechanisms studied in WP1. Exploitation covers Boolean computing on events, ordering, classifying, filtering, accumulating, mean-value calculation, and finally triggering of an appropriate action. This task intends to identify how to write these second level instrumentation threads (with respect to the first level instrumentation threads studied in WP1)that are designed to be the reactive part of the online monitoring, for they decide to trigger the next step or not. Next step can either be further analysis through test (2c) or direct remapping (WP3).
 || T0+6 → T0+24||
 || Status : '''not achieved yet'''||
+
 [[BR]]
-|| '''Task  2.c''' :  Functional/structural test, Task manager : LIP6, Partners : LIP6. The main objective of this task is to identify the failing component(s) of the MP2SoC architecture, in reaction to the alert triggering. Faulty components can be processors, RAMs within a Processing Element (PE), or routers interconnecting the main PEs. Thus, functional/structural software/hardware architectures and methods must be defined to allow a quick targeting of the faulty part. Different strategies depending on the level of accuracy are to be experimented: stop at first fail, identify all failing components within the PE … It must be noticed in this task that the structural test is not intended to localize a faulty gate or a faulty transistor, the objective is rather to find which component should be deactivated and not considered during the remapping step. This obviously implies the use of on-chip functional resources for test purpose. 
+|| '''Task  2.c''' :  Functional/structural test, Task manager : '''LIP6''', Partners : '''LIP6'''. The main objective of this task is to identify the failing component(s) of the MP2SoC architecture, in reaction to the alert triggering. Faulty components can be processors, RAMs within a Processing Element (PE), or routers interconnecting the main PEs. Thus, functional/structural software/hardware architectures and methods must be defined to allow a quick targeting of the faulty part. Different strategies depending on the level of accuracy are to be experimented: stop at first fail, identify all failing components within the PE … It must be noticed in this task that the structural test is not intended to localize a faulty gate or a faulty transistor, the objective is rather to find which component should be deactivated and not considered during the remapping step. This obviously implies the use of on-chip functional resources for test purpose. 
+|| T0 → T0+24||
+|| Status : '''not achieved yet'''||
+
+[[BR]]
+|| '''Task  2.d''' :  Event database access/history primitives, Task manager : LIP6, Partners : ALL. This task aims at defining the Application Program Interface (API) of the AIM database, in interaction with the API defined in task 1d. An AIM is a collection of logged events corresponding to a single monitored phenomenon (exact locations and characteristics). In particular, this task is to define all the means needed to manipulate/enhance a database of AIMs, classified by observed phenomenon (temperature audit of the SoC, accurate identification of the faulty parts, communication contention points, etc), as well as their history for backtrack purposes. 
 || T0+6 → T0+24||
-|| Status : '''not achieved yet'''||  
-
+|| Status : '''not achieved yet'''||