Views
5 years ago

Synthèse de haut-niveau de contrôleurs ultra-faible consommation ...

Synthèse de haut-niveau de contrôleurs ultra-faible consommation ...

tel-00553143, version 1

tel-00553143, version 1 - 6 Jan 2011 114 Proposed system model and design-flow for SM synthesis � a re-loadable state transition table that defines each valid state transition and its associated callback function. Each callback function should satisfy the run-tocompletion semantics to maintain the instantaneous state transition semantics. This phenomenon is achieved by using a protected shared resource like mutex. In SenOS, kernel and callback library are statically built and stored in flash ROM of a sensor node whereas the state transition table can be reloaded. The SenOS can handle multiple applications by means of multiple co-existing state transition tables and provide concurrency among applications by switching state transition tables. Each state transition table defines an application and during preemption, the kernel saves the present state of the current application, restores the state of the next application, and changes the current state transition table. After presenting the existing related work about the most commonly used OS by the WSN community, in next section, we present the important features and notions used in our system-level execution model and compare them wherever possible to those of conventional OS-based WSN systems. 5.4 Features of our proposed execution model First of all, we want to clarify that our goal (in this work) is not to propose a new model of computation for WSN computation subsystem. We rather see our proposed approach as a simple system-level execution model chosen so as to be a good match for what we think is a promising architectural solution for WSN nodes. The important notions or features proposed in our execution model are discussed in the following sections. 5.4.1 Events and commands In our approach, we use command and event message structures between the SM and hardware micro-tasks similar to those of TinyOS. A command is an enable signal generated by the SM toward a hardware micro-task signaling the start of its operation. On the other hand, an event is a control signal generated by a hardware micro-task to the SM announcing the termination of its job. Dotted lines in Figure 5.4, represent command signals driven by the SM to the micro-tasks and shared memories. Solid lines represent the events sent back to the SM. Events can be of two types: � internal event: an event that is generated by a hardware micro-task indicating its termination or preemption (in case of a sub-routine call). � external event: an event that is generated by an external peripheral that can serve as wake-up call from shut-down mode using a timer, arrival of a data packet at RF interface or a periodic value received at the sensor interface.

tel-00553143, version 1 - 6 Jan 2011 Features of our proposed execution model 115 5.4.2 Concurrency management Both TinyOS and Contiki allow the programmer to express concurrency in their applications through the use of specialized constructs such as Protothreads for Contiki and Tasks for TinyOS. One of the goals of such non-standard constructs is to help reducing context switching and task scheduling overhead. In our approach, as we rely on several physically distinct hardware micro-tasks, we provide a natural support for concurrency and task-level parallelism, and do not have to pay for any context switching overhead. Similarly, scheduling does not have any execution time overhead, even if taking into account the extra silicon area required by the SM. Another advantage of our approach lies in the fact that shared resources such as memory or I/O ports are much easier to handle than in a standard multi-processor architecture, thanks to power-gating. MT2 MT3 Arbiter (a) Access control logic in conventional systems Local Memory A’ System Monitor MT2 MT3 (b) Access control logic in our system Figure 5.6: Access control simplicity of power-gated modules. Local Memory A’ We introduce a resource constraint in our execution model that no two hardware micro-tasks sharing write-access to a shared resource can be active (powered-on) at the same time. Thanks to this constraint, we can save the typical extra tri-state (or multiplexer) logic used to share data/address bus lines, which results in savings both in terms of power and area. Figure 5.6 shows this concept while comparing the access control logic in our system compared to a conventional one. 5.4.3 Task hierarchy In our execution model, we offer two ways for handling sub-routine calls made within the C-specification of a hardware micro-task. The first one is straightforward and consists in inlining the sub-routine calls, this increases the task granularity and is acceptable for small sub-program calls. The second one is more complex and consists in generating a new hardware micro-task dedicated to the sub-program execution. In latter case, the parent (i.e. caller) micro-task invokes the child micro-task (through the SM). As the child micro-task is also power-gated, it only marginally contributes to the static power budget, while helping in maintaining a

Synthèse, caractérisation et intérêt biomédical de (glyco ...
Synthèse, caractérisation et polymérisation par ouverture de cycle ...
Analyse et synthèse de sons de piano par modèles physiques et de ...
Emission gamma de haute énergie dans les systèmes binaires ...
Martin Teichmann Atomes de lithium-6 ultra froids dans la ... - TEL