Model-Based Design for Embedded Systems- P34 pptx

Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 296 2009-10-2 296 Model-Based Design for Embedded Systems relation (the mapping). The MIC is supported by a set of tools that can cre- ate and manage various modeling languages. For instance, the generic modeling environment (GME) has been designed to facilitate the construction and the manipulation of domain-specific modeling languages, by providing a way of specifying an abstract as well as a concrete syntax (textual or graph- ical), including well-formed constraints and static semantics. The language design activity is again based on the UML and the Object Constraint Lan- guage (OCL) constraints [48], which are used as meta-languages. However, the resulting language need not be related to the UML at all. The manipulation in the GME also includes the possibility to merge and compose languages at the syntactic level, by identifying relationships between elements of different languages. Languages designed in the GME can be manipulated using GReAT [1] to implement a variety of model transformations based on standard traver- sal patterns or on graph-rewriting rules (called meta-generators). These tools are used to convert models automatically between languages, or to gener- ate implementation models. Designs can be verified using MILAN [4,36]. MILAN supports the integration of different simulators at various levels of granularity using model interpreters, and integrates the design-space exploration tool, DESERT [47]. DESERT allows the designer to express the flexibility in a platform by specifying structural constraints in the OCL. An efficient symbolic technique is used to explore only the architectures that satisfy the constraints, thus pruning a large part of the design space. Performance eval- uation is then carried out using lower-level simulators capable of providing accurate performance measures. Unlike the GME, our work is not focused on the design of modeling languages; rather we look at ways of using existing modeling languages without the need of introducing new ones. To do so, we use special ports and connections to coordinate components that belong to different domains of computation, possibly expressed with different languages; wrappers bridge between different activation and scheduling protocols. Adaptors represent the interfaces between wrappers. Adaptors are in general written explicitly by users. We developed a theoretical framework where adaptors are inter- preted as the result of a mapping of the heterogeneous component wrappers into a common semantic domain where communication can be specified for- mally and then a mapping back into the original domain of the components. In this sense, our approach is closer to that used in MILAN, where model interpreters can be seen as adaptors. However, MILAN makes no attempt at describing the interaction as a formal relation, and is limited to integrating simulation environments, rather than providing tools to study and define heterogeneous compositions. Our architecture exploration paradigm differs substantially from that employed in DESERT. In particular, we use functional and scheduling constraints, instead of structural constraints, and we are thus able to relate the execution of a function with its implementation on an architecture without Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 297 2009-10-2 Platform-Based Design and Frameworks: METROPOLIS and METRO II 297 resorting to low-level simulators. However, the combined use of structural and scheduling constraints for fast generation and exploration of architectures is a promising avenue of future research. PtolemyIIisadesignenvironmentforheterogeneoussystemsthatconsists of several executabledomains of computation thatcan be mixedin a hierarchy controlled by a global scheduler [12]. Each MoC is described operationally in terms of a common executable interface. For each model, a “director” determines the order of activation of the components (or actors). Similarly, communication isdefined in terms of a common interface. A MoC, or domain, in Ptolemy IIis a pair composed ofa director togetherwith an implementation of the communication interface, called a “receiver.” The approach to heterogeneity in Ptolemy II is strictly hierarchical. This implies that each node of the hierarchy contains exactly one domain, and that each component interacts with the rest of the system using the specific communication mechanism selected by the domain for the hierarchy node it belongs to. Domains only interact at the boundary between two different levels of the hierarchy. SystemC-H is a heterogeneous extension to SystemC that provides additional domains of computation, such as dataflow and hierarchical FSMs [50]. The extension follows the same idea as in Ptolemy II of defining hierarchical directors that follow a predetermined interface and a protocol for scheduling that includes the computation of preconditions for execution, a fixed-point loop, and a wrap-up phase. The authors demonstrate an increase in the simulation efficiency due to the possibility of statically scheduling the dataflow portion. The hierarchical approach to heterogeneity of Ptolemy II and SystemC-H is nicely structured and is an excellent environment for experimentation. The structure, however, also imposes limitations on the amount of heterogeneity that can be achieved. More importantly, the relationship between different models is implicit in the way the execution protocol schedules the activation of the directors and the transfer of information through the receivers. This makes it difficult to predict the outcome of a hierarchical heterogeneous composition or to study its properties. In addition, the scheduling protocol is hardwired in the framework, and, therefore, it cannot be changed without altering the core of the tools. As a result, the relationship between different models (i.e., the abstraction and the refinement) is fixed, unless boundary components are used to explicitly translate between different modeling con- ventions. For example, this technique is used in Ptolemy II to translate from the discrete to the continuous domain, and vice versa, through special trans- ducers. This technique, however, appears to relax the requirement for strict hierarchical heterogeneity. Our approach to heterogeneity is instead based on establishing clear abstraction and refinement relationships between models. These are typically constructed through the use of a common semantic domain, although this is not strictly necessary. The idea is then to construct adaptors that coordinate the execution of different models and that are consistent with the chosen abstractions and refinements. Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 298 2009-10-2 298 Model-Based Design for Embedded Systems Functional languages have also been used to support SLD. In ForSyDe [53], the system is initially specified as a deterministic network of fully synchronous processes that communicate over sequences of events, a model that facilitates the functional description by abstracting away detailed timing. Compliance with the model is enforced by expressing the basic com- binatorial behaviors using functions free of side effects, and by generating processes using higher-order process constructors. Haskell has been chosen as the concrete language for expressing the model, since it natively supports higher-order constructs. The specification is then refined into an implementation by applying a series of network transformations that may or may not preserve the semantics of the network. These transformations can, for example, partition the system into subdomains that run at different speeds (the model is therefore no longer fully synchronous), interfaced through up- and down-converters. When the desired structure has been obtained, processes are converted into hardware or software, depending on the chosen implementation. The basic ForSyDe model was then extended to cover a larger array of MoCs [30], and has been implemented in Stan- dard ML in the SML-Sys project [40], as well as in C++ [41]. There, the ini- tial assumption of a fully synchronous system is dropped in favor of an untimed model similar to Kahn process networks [31]. In addition, synchronous, clocked, and timed models can be used for refinement. How- ever, SML-Sys appears to be more focused on heterogeneous design, rather than on transformational refinement. For this reason, SML-Sys relies on ForSyDe for network transformations, while more complex interfaces have been introduced to bridge the gap between different subdomains. More recently, the same group has developed a front-end to both SML-Sys and ForSyDe, called the EWD [39], which captures their common structure into a GME-based meta-model, and provides some code-generation facilities to target both Standard ML and Haskell. (The behavior code, other than constructors and combinators, must still be manually annotated.) Because the static semantics can be expressed in a GME meta-model, the front- end is able to catch errors at the time of design before compilation is attempted. Unlike ForSyDe, M ETROPOLIS supports nondeterministic systems, a choice that renders analysis more complex, but greatly simplifies the description of the environment of the system. As the design is refined, nondeterministic components replace deterministic ones in the system. The transformation- based refinement in ForSyDe has clear advantages in terms of the ability to prove correctness and maintain consistency with the original specification. However, the distinction between the functionality and the architecture is lost, and a change of mapping may require substantial restructuring of the system. Our approach to mapping, instead, makes this task simpler, since only the mapping function must be changed. Heterogeneity is addressed in SML-Sys, using domain interfaces that add or remove events from the event sequences. These interfaces, or adaptors, are somewhat arbitrary. We also Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 299 2009-10-2 Platform-Based Design and Frameworks: METROPOLIS and METRO II 299 employ adaptors, but we justify their use by reasoning on the semantics of the interaction supported by the refinement of communicating models onto a common semantic domain. Also inspired by functional languages is the heterogeneous SLD language, Rosetta [2,34]. In Rosetta, an MoC, or domain, is described declaratively as a set of assertions in a higher-order logic. The definition includes the objects of the discourse, such as variables that represent time and power, or a transition relation, to model behaviors. The assertions then axiomatically determine the interpretation of these quantities as properties that they must satisfy. Different domains can be obtained by extending a definition in a way similar to the subclassing relation of a type system. The extended domain inherits all the assertions (the terms) of the original domain, and adds additional constraints on top of them. Domains that are obtained this way are automatically related by an abstraction/refinement relationship. Domains that are unrelated can still be compared by constructing functions, called interactions that (sometimes partially) express the consequences of the properties and the quantities of one domain onto another. This process is particularly useful for expressing and keeping track of constraints during the refinement of the design. In contrast to Rosetta, the relationship between the function and the architecture in M ETROPOLIS is not described explicitly as a function (the interactions), but rather as a mapping and an annotation process at the event level. Annotations at this level are simpler to express, and can be used directly for simulation. Conversely, domain interactions are more difficult to manipu- late, since they are defined at the level of the domain, but may, in principle, be used to derive stronger results via formal reasoning. Tools that can take full advantage of the Rosetta representation are, however, still in the devel- opment phase. The separation between computation and coordination is central to the behavior-interaction-priority (BIP) framework [9]. In the BIP, a system specification is divided into three layers. At the bottom layer, the behavior of the system is specified as a collection of independent finite-state transition systems (components), which communicate with the environment through ports. Each transition of a component is activated by an interaction, which is a subset of its ports. At the middle layer, a set of connectors specify the possible interactions of the components. That is, connectors identify the sub- sets of the ports of the whole system that can participate in interactions, and, therefore, activate a transition. Different connectors, and different ways of linking them, define different kinds of interactions that can be used to model such diverse communication paradigms as asynchronous broadcasts to fully synchronous systems. Connectors often result in nondeterministic systems. Determinism can be recovered by using the third layer, where priorities can be imposed on the interactions to induce a unique choice of transition. Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 300 2009-10-2 300 Model-Based Design for Embedded Systems One of the strengths of the BIP framework is the ability to check certain properties, such as deadlock freedom, by composition. This is obtained at the expense of a more complex coordination scheme, involving the connectors, which must determine the global set of possible interactions. This may adversely impact simulation performance, and, for certain communication paradigms, it may require a number of connectors that grow exponentially with the number of components. Recently, Bli- udze and Sifakis have proposed symbolic and incremental techniques to get around these problems [11], which are currently being evaluated in the framework. We are also interested in global properties, such as those that have to do with the resource consumption of the architecture. The quantities associated with these properties are, however, determined in centralized components, namely, the annotators and the schedulers. Sched- ulers can be seen as forms of connectors, since they regulate the execution of the system. Unlike the BIP, we favor an imperative description, as opposed to a declarative one, that is simpler to develop and reuse, and that can be optimized for a high performance. Annotators are not present in the BIP framework, which is not intended for architectural exploration. FunState [58], an evolution of the SPI system [66], is an internal design representation that supports mixing control and dataflow. This is achieved by a flexible and rich underlying model. In its basic form, the model includes functions that communicate over queues and arrays of registers. Functions produce and consume a specified number of data tokens from the queues and are characterized by defined execution latency. The activation of functions is controlled by an FSM, whose transitions are labeled with condi- tions on the number of tokens present in the queues. The FSM controls the progress of the execution, so that tokens are consumed and produced at a time consistent with the execution latency of the functions. In addition, the user can set timing constraints on the data path to model deadlines and other performance requirements. Formal verification, based on symbolic model checking and on timed automata techniques, can be applied to check properties of the system, including the satisfaction of the timing constraints and the boundedness of the number of tokens in the queues. This is particularly useful for studying schedulability, for which FunState has been specifically developed. While the strength of FunState is in formal verification, its design as an internal representation makes it more difficult to use for architectural and design-space explorations. First, FunState lacks the ability to define arbitrary performance metrics (other than time), which is important to model different aspects of an architecture. In addition, the FunState model does not dis- tinguish between the function and the architecture. Instead, it can be seen as a deployment model, where the interaction between the two has already been resolved and annotated by selecting timing and appropriate scheduling policies. Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 301 2009-10-2 Platform-Based Design and Frameworks: METROPOLIS and METRO II 301 10.6 Case Studies The following sections will illustrate two case studies each performed in the M ETRO II design environment. The first discusses a universal mobile telecom- munications system (UMTS), which illustrates how easily external models can be imported into M ETRO II, two distinct architecture-modeling styles, and analyzes the M ETRO II simulation infrastructure. The other case study is an indoor air quality example where we examine how to integrate M ETRO II with other design tools for continuous-time systems. 10.6.1 UMTS We focus on the user equipment domain of the UMTS protocol [52], which is of interest to mobile devices and is subject to stringent implementation constraints. The protocol stack of the UMTS for the user equipment domain has been standardized by the 3rd generation partnership project (3GPP) up to the network layer, including the physical (PHY) and data link layers (DLL). Our model includes the implementation of the DLL layer and the functionality of the PHY layer. We enumerate the 48 different points in the design space that were explored. We detail the estimated execution times and the processing- element utilization, the design effort, the simulation cost breakdown, and an analysis of how events are processed during each simulation phase in M ETRO II. 10.6.1.1 Functional Modeling The UMTS DLL layer contains the radio link control (RLC) and the medium access control (MAC) sublayers and performs general packet forming. The RLC communicates with the MAC through different logical channels to dis- tinguish between the user, signaling, and the control data. Depending on the required quality of service, the MAC layer maps the logical channels into a set of transport channels, which are then passed to the Physical layer. The Physical layer handles lower-level coding and modulation in order to reduce the bit error rate of the transmitted data. For the purposes of this case study, the UMTS application was largely separated into both receiver and transmitter portions and then further by the RLC and the MAC functionalities. Simulation consists of processing 100 packets, each packet being 70 bytes. The functional model is shown in Fig- ure 10.10. The semantics is dataflow, with blocking read and blocking write semantics for the FIFOs. The functional model is described as a process network or an actor-oriented model, where concurrently executing processes communicate with each other through point-to-point channels. The communication semantics can be adjusted on a per-channel basis. For instance, the data transfer between a pair of processes may take place with Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 302 2009-10-2 302 Model-Based Design for Embedded Systems TR buffer Segmentation RLC header add Ciphering FIFO TrCH type switch CT MUX TR format se PHY CT DEMUX Rx TCH type switch Deciphering Reassembly RLC RLC MAC MAC Receiver Transmitter write() read() read() write() read() write() Transmitter MAC dataflow RLC header rem Transmitter RLC dataflow Receiver dataflow FIGURE 10.10 UMTS M ETRO II functional model. rendezvous semantics or blocking read, nonblocking write semantics. In M ETRO II, there are a number of ways in which this coordination between processes may be specified. Two such mechanisms are detailed in Figure 10.11. In the explicit synchronization style, an imperative code is written to pre- vent process P 2 from reading data out of an empty FIFO F1, and also pre- venting it from writing data to a full FIFO F2. The code makes use of interface methods provided by the FIFOs as well as events exposed from within the FIFOs through view ports (not shown in the figure). This imperative specification is quite similar to what might be specified in SystemC. These interface methods will themselves propose “begin” and “end” events to the system for scheduling along with any other methods used to query the state of the FIFOs. These additional events have the ability to affect simulation, as will be discussed in Section 10.6.1.4. The second specification style uses constraints to enforce the same behavior. Now, instead of the imperative code being specified in the Phase 1 components, the corresponding constraints are passed to the Phase 3 constraint solver. This separates computation from coordination, and different coordination models can be used for the same process P 2 . This separation is similar to the concept of a “director” within the Ptolemy [38] environment, but within M ETRO II, the coordination may be specified declaratively. The first style has more events and may also cause the Phase 1 processes to become suspended due to internal blocking (as opposed to blocking due to event disabling in Phase 3). The benefits of the second style in this regard are described in Section 10.6.1.4. Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 303 2009-10-2 Platform-Based Design and Frameworks: METROPOLIS and METRO II 303 F1 F2 if (in_port–>num_available() ==0) in_port–>wait(F1.write_event) if (out_port–>num_available() ==F2.size) out_port–>wait(F2.read_event) Annotator Constraint1 ConstraintN E1 E2 EN M2_manager 1. Base phase 2. Annotation phase 3. Constraint-solving phase Explicit synchronization Constraints Propose write event Propose read event Annotate events P 3 P 2 P 1 P 3 P 2 P 1 F2F1 Option #2 declarative constraints enforce semantics Option #1: Imperative code written to enforce operational semantics FIGURE 10.11 Two options for expressing coordination. Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 304 2009-10-2 304 Model-Based Design for Embedded Systems 10.6.1.2 Architectural Modeling The architecture model assigns one task for each of the 11 UMTS components. (The TR buffer and PHY were not mapped as they represent the environment.) The operating system (OS) employs three different scheduling policies for each processing element. The first is a round-robin scheduler where each processing element is simply selected sequentially. This is a cyclic process beginning with processing element 0 and moving through the number of PEs. If a PE does not have a request pending then the next PE in the list is allowed to proceed. The second algorithm is a priority- based scheduling algorithm where higher priorities are assigned to tasks with higher processing requirements. These requirements are determined during the pre-profiling stage. Preemption is not employed as in the timed functional model. Priority scheduling here examines all the requests for processing in a given round and selects the one with the highest priority. The selected priority is noted and in the next round it cannot be chosen again if there are still events pending from previous rounds. The final algorithm is a first-come-first-serve (FCFS) algorithm, which marks requests with the round that they enter the system and ensures that they are handled in order of appearance. In the event of a tie, this falls back to a round-robin scheme. The runtime processing elements were supplied with the C code reflect- ing the kernels of each UMTS component. The runtime processing element available for this case study is a cycle-accurate datapath model of the Leon 3 Sparc processor. The pre-profiled processors use the same code but carry out offline characterization, as detailed in [42] and [24]. The processors profiled were the ARM7, the ARM9, and Xilinx’s MicroBlaze. All of the processing elements are common in embedded and SoC applications and are widely documented. The architecture models to be discussed in this work are composed of the following three portions. Figure 10.12 illustrates these three portions. 1. Tasks—Tasks are lightweight and active components in the architecture model. The thread for each task constantly proposes begin events for its provided services. Mapping creates a rendezvous constraint between the event generated by the task thread (in this case, request_job)andthe functional event. Therefore, there is a 1:1 mapping between these tasks and functional components. Because of the rendezvous constraint, the task remains blocked until the corresponding event from the functional model is proposed. Step 1 in Figure 10.12 illustrates the task’s role in architecture model execution. 2. Operating System—An OS is used to assign tasks to processing elements (in a many-to-one relationship). In addition, it also carries out Phase 1 scheduling—reducing the work to be done in Phase 3. This is done by pruning the events that are proposed in the first phase. An investigation of scheduling policies will be seen in Section 10.6.1.4. An OS is an active component with N threads (where N is the number of Nicolescu/Model-Based Design for Embedded Systems 67842_C010 Finals Page 305 2009-10-2 Platform-Based Design and Frameworks: METROPOLIS and METRO II 305 Runtime processing element 1 os_port: request_job( ) Profiled processing element 1 Runtime processing1 Cycle-accurate pipeline Instruction memory Run_proc( ) Request queue Task1 Operating system Thread Thread run_jobN( ) Thread run_job1( ) Application code Request_job_event 1. Active component (task) continually attempts to propose jobs to OS 2. OS threads wait for jobs to come in 4. Threads then propose jobs on specific processing elements Run_job_event Run_proc( ) 3. OS schedules events to run by unblocking threads 5. Thread uses task information to “set the program” for processing element 6. Processing elements run and pass their cycle counts back to the OS 7. OS updates annotation table based on processing- element cycle count results Task 2 Task N Runtime processing element 2 Runtime processing element N Profiled processing element N ARM7 ARM9 microblaze FIFO Shared mem MPSoC Design FIGURE 10.12 Topology of architecture service environment. processing elements it controls). It maintains a queue of requested jobs which processing elements query to decide if they will execute or not. The queue contains events proposed for processing, which processing elements they wish to use, the rounds in which they were proposed, and the statically assigned priorities for the events. Scheduling controls how events are added to and removed from this queue. The access to this queue is coordinated such that there is a limited number of outstand- ing requests for a given processing element. Steps 2–5 in Figure 10.12 illustrate the OS’s role in the architecture model execution. 3. Processing Element—The third piece of the architecture platform consists of the actual processing elements. Once the OS decides to run a task request, it calls the corresponding “run_proc()” function call on one of its N required ports. The interface supported by all processing elements is the same (to provide modularity and flexibility), but there . refinements. Nicolescu /Model-Based Design for Embedded Systems 67842_C010 Finals Page 298 2009-10-2 298 Model-Based Design for Embedded Systems Functional languages have also been used to support SLD. In ForSyDe. Nicolescu /Model-Based Design for Embedded Systems 67842_C010 Finals Page 296 2009-10-2 296 Model-Based Design for Embedded Systems relation (the mapping). The. induce a unique choice of transition. Nicolescu /Model-Based Design for Embedded Systems 67842_C010 Finals Page 300 2009-10-2 300 Model-Based Design for Embedded Systems One of the strengths of the