Model-Based Design for Embedded Systems- P20 pptx

Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 546 2009-10-2 546 Model-Based Design for Embedded Systems implicitly the synchronization. This property verifies that after a cycle exe- cuted by each model, both are at the same time stamp (and by consequence are synchronized) Definition: Invariantly both processes in the Start location (initial state) imply the time in the continuous domain t c isequalwiththetimeinthe discrete domain t d . P4 Causality principle (liveness property) The causality can be defined as a cause andeffectrelationship. The causal- ity of two events describes to what extent one event is caused by the other. The causality is already verified by P3 for scheduled events. However, when a state event is generated by the continuous domain, the discrete domain has to detect this event at the same precise time (the cause precedes or equals the effect time) and not some other possible event existing at a different time in the continuous domain. Definition: Invariantly both processes in the StEvDetect location (detection of state event) imply the time in the continuous t c is equal with thetimeinthediscretet d . 16.6.6 Definition of the Internal Architecture of the Simulation Interfaces The overall continuous/discrete simulation interface is formally defined using the DEVS formalism. As shown in Figure 16.4, the interface is described as a set of coupled models: the continuous domain interface (CDI), the discrete domain interface (DDI), and the co-simulation bus. Figure 16.12 shows the atomic modules composing the interface used in our implementation. The specific functionalities of the interfaces were presented in Sec- tion 16.4.2. In terms of internal architecture, the blocks assuring these fea- tures are For the Continuous Model Simulation Interface • The State Event Indication and Time Sending block (SETS) • The Signal Conversion and Data Exchange block (SCDE) • The Event Detection block (DED) • The Context Switch block (CS) For the Discrete Model Simulation Interface • The End of Discrete Simulation Cycle Detection and Time Sending block (DDTS) • The Data Exchange block (DE) • The Event Detection block (DEC) • The Context Switch block (CS) These atomic modules are forming the co-simulation library and the co- simulation tools enable their parameterization and their assembly in order to generate a new co-simulation instance. Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 547 2009-10-2 Generic Methodology for the Design 547 Continuous/discrete global simulation model Continuous/discrete simulation interface Continuous domain simulation interface-CDI Continuous model Discrete model Data exchange DE Context switch CS Co-simulation bus Elements from the co-simulation library Signal conversion and data exchange SCDE Context switch CS State event indication and time sending SETS Event detection DED End of discrete simulation cycle detection and time sending DDTS Event detection DEC Discrete model simulation interface-DDI FIGURE 16.12 The hierarchical representation of the generic architecture of the co- simulation model with the elements of the co-simulation library defined. (From Gheorghe, L. et al., Formal definition of simulation interfaces in a continuous/discrete co-simulation tool, Proceedings of the 17th IEEE Inter- national Workshop on RSP, Chania, Crete, Greece, pp. 186–192, 2006. With permission.) End of discrete simulation cycle detection and time sending DDTS Discrete domain interface DDI Continuous domain interface CDI Discrete/continuous data exchange Flag from the discrete to the continuous model Flag from the continuous to the discrete model Time of state event tse Time of the next scheduled event in the discrete simulator td State event indication and time sending SETS Data exchange DE Context switch CS Context switch CS Event detection DEC Event detection DED Signal conversion and data exchange SCDE Data to/from the discrete simulator DS Data to/from the continuous simulator DS FIGURE 16.13 Internal architecture of the continuous/discrete simulation interface. (From Gheorghe, L. et al., Formal definition of simulation interfaces in a continuous/discrete co-simulation tool, Proceedings of the 17th IEEE Inter- national Workshop on RSP, Chania, Crete, Greece, pp. 186–192, 2006. With permission.) Figure 16.13 presents the atomic modules interconnection in each domain specific simulation interface as well as the signals and interactions between the interfaces. Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 548 2009-10-2 548 Model-Based Design for Embedded Systems The internal architecture is defined as a set of coupled modules that respect the coupled modules DEVS formalism as presented in Section 16.6.1: -N interface =(X,Y, D,{M d |d ∈ D}, EIC,EOC,IC ) -X ={(p d , v d )|p d ∈ InPorts, v d ∈ Xp d } -Y ={(p d , v d )|p d ∈ OutPorts, v d ∈ Yp d } -Xp d, Yp d = values for input ports, respectively output ports -InPorts =P in,c ∪P in,d ∪P in,td ∪P in,tse ∪P in,flag where P in,c – set of ports receiving data from the continuous model; P in,d –set of ports receiving data from the discrete model (via the co-simulation bus); P td – port receiving the timestamp of the next discrete event P in,flag – port receiving the command for the context switch - OutPorts =P out,c ∪P out,d ∪P out,td ∪P out,tse ∪P out,flag P out,flag, P out,c ,P out,d are defined similarly to P in,flag,, P in,c and P in,d - D = {“Continuous Domain Interface” (with associated model N interfaceCDI ), “Discrete Domain Interface” (with associated model N interfaceDDI ), “co-simulation bus” (with associated model M cosim )} −M d = (N interfaceCDI , M interfaceDDI , M cosim ) −EIC ={((N interface ,“in  c,1 ), (N interfaceCDI ,“in  c,1 )); ; ((N interface ,“in  c,n ), (N interfaceCDI ,“in  c,n )); ((N interface ,“in  d,0 ), (N interfaceDDI ,“in  d,0 )); ; ((N interface ,“in  d,m ), (N interfaceDDI ,“in  d,m ))} −EOC ={((N interfaceCDI , “out  c,1 ), (N interface ,“out  c,1 )); ; ((N interfaceCDI , “out  c,p ), (N interface , “out  c,p )); ((N interfaceDDI , “out  d,1 ), (N interface , “out  d,1 )); ; ((N interfaceDDI , “out  d,q ), (N interface , “out  d,q ))} −IC ={((N interfaceCDI , op CDI ), (M cosim , ip cosim ))|N interfaceCDI , −M cosim ∈ D, op CDI ∈ OutPorts CDI, ip cosim ∈ InPorts cosim }∪ {((N interfaceDDI , op DDI ), (M cosim , ip cosim ))|N interfaceDDI , M cosim ∈ D, op DDI ∈ OutPorts DDI, ip cosim ∈ InPorts cosim }∪ {((M cosim , op cosim ), (N interfaceCDI , ip CDI ))|N interfaceCDI , M cosim ∈ D, op cosim ∈ OutPorts cosim, ip CDI ∈ InPorts CDI, }∪ {((M cosim , op cosim ), (N interfaceDDI , ip DDI ))|N interfaceDDI , −M cosim ∈ D, op cosim ∈ OutPorts cosim, ip DDI ∈ InPorts DDI, }[12] We show here the atomic module co-simulation bus that can be formally defined as follows: - X. ={(p d , v d ) |p d ∈InPorts, v d ∈Xp d } - Y ={(p d , v d ) |p d ∈OutPorts, v d ∈Yp d } Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 549 2009-10-2 Generic Methodology for the Design 549 - InPorts = P in,c ∪P in,d ∪P in,td ∪rmP in,tse ∪P in,flag - OutPorts = P out,c ∪P out,d ∪P out,td ∪P out,tse ∪P out,flag where P in,c ,P in,d P in,td ,P in,tse ,P in,flag P out,c ,P out,d ,P out,td ,P out,tse, P out,flag as well as Xp d , Yp d were previously defined. States triplet S: (phase * σ * job) where: phase: (“passive,” “active”) σ :  + 0 advance time job: (“store,” “respond”) S ={“passive,” “active”} *  + 0 * {“store”, “respond”} δ ext ((“passive” * σ * job), e, x))= (“passive,” σ –e, x), if x =0 (“active”, σ –e, job), if x! =0 δ int (s) =(“active”, σ,job) λ (“active,” σ,job)={“store”, “respond” } t a (phase, σ,job)=σ The architecture of the discrete domain interface and the continuous domain interface are also formally defined as a set of coupled modules. For- mal descriptions for DDI and CDI respect the coupled module DEVS formal- ism. Each element of the structure follows the concepts presented in Section 16.6.1 and that were applied for the overall continuous/discrete simulation interface. 16.6.7 Analysis of the Simulation Tools for the Integration in the Co-Simulation Framework The previous steps that describe the gradual formal definition of the simu- lation interfaces and the required library elements are independent of the different simulation tools and specification languages used generally for the specification/execution of the continuous and discrete subsystems. After the analysis of the existing tools we found that Simulink is an illustra- tive example of a continuous simulator enabling the control functionalities that were presented in Section 16.4.5. These functionalities can be added in generic library blocks and a given Simulink model may be prepared for the co-simulation by parameterization and addition of these blocks. Several discrete simulators present the characteristics detailed in Section 16.4.5. SystemC is an illustrative example. Since it is an open source, SystemC enables the addition of the presented functionalities in an efficient way—the scheduler can be modified and adapted for co-simulation. In this way, the co- simulation overhead may be minimized. However, the addition of simula- tion interfaces is more difficult than in Simulink because the specifications in SystemC are textual and a code generator is required to facilitate the addition of simulation interfaces. The automatic generation of the co-simulation inter- faces is very suitable, since their design is time consuming and an important source of errors. The strategy currently used is based on the configuration of the components and their assembly. These components are selected from a co-simulation library. Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 550 2009-10-2 550 Model-Based Design for Embedded Systems 16.6.8 Implementation of the Library Elements Specific to Different Simulation Tools The implementation for the validation of continuous/discrete systems was realized using SystemC for the discrete simulation models and Simulink for the continuous simulation models. For Simulink, the interfaces are functional blocks programmed in C++ using S-Functions [24]. These blocks are manipulated like all other compo- nents of the Simulink library. They contain input/output ports compatible with all model ports that can be connected directly using Simulink signals. The user starts by dragging the interfaces from the interface components library into the model’s window, then parameterizes them, and finally con- nects them to the inputs and the outputs of his model. For SystemC, in order to increase the simulation performance, part of the synchronization functionality has been implemented at the scheduler’s level, which is a part of the state event management and the end of the dis- crete cycle detection (detects that there are no more delta cycles at the cur- rent time). For the generation of the co-simulation interfaces for SystemC, the implementation of a code generator was necessary. This script has as input user-defined parameters such as sampling periods, number and type of ports, and synchronization ports. 16.7 Formalization and Verification of the Interfaces One of the key issues for the automatic generation of co-simulation inter- faces is the rigorous definition of the behavior and architecture of simula- tion interfaces and this can be achieved by their formalization and formal verification in terms of behavior. Formal definitions can be used to develop easy-to-verify designs [16]. On this mathematical foundation one can define the criteria that allows for the automatic selection of the components from the co-simulation library and the automatic generation of the co-simulation interfaces. This section presents the formalization and the verification of the co-simulation interfaces. 16.7.1 Discrete Simulator Interface This section presents the operational semantics of the discrete simulation interfaces (DSI). The semantics were defined with respect to the synchroniza- tion model presented in Section 16.6.1, using the DEVS formalism. Table 16.2 presents a set of rules that show the transitions between states. For all the rules, the semantics of the global variable flag is related to the context switch between the continuous and discrete simulators. When the flag is set to “1,” the discrete simulator is executed. When it is “0,” the con- tinuous simulator is executed. The global variable synch is used to impose Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 551 2009-10-2 Generic Methodology for the Design 551 TABLE 16.2 Operational Semantics for the DSI Nr. Rule 1. synch = 1 ∧ flag = 1 ∧(x dk , t dk ) = δ ext ((x dk , t dk ),0,x) ((x dk ,t dk ), ∞) ?DataFromDisc −−−−−−−→ ((x dk , t dk ),0) !(data,t dk+1 ((x dk ,t dk )));flag:=0 −−−−−−−−−−−−−−−−→ ((x dk , t dk ), t dk+1 ) 2. synch = 0 ∧ flag = 1 ∧¬stateevent ∧ (x dk , t dk ) = δ ext ((x dk , t dk ),0,x) ((x dk , t dk ), e dk ) ?Event −−→ ((x dk , t dk ),0) ?data;synch:=1 −−−−−−−→ ((x dk , t dk ),0) !DataToDisc −−−−−−→ ((x dk+1 , t dk+1 ), e dk+1 ) 3. synch = 0 ∧ flag = 1 ∧stateevent ∧(x dk , t dk ) = δ ext ((x dk , t dk ),0,x) ((x dk , t dk ), e dk ) ?Event −−→ ((x dk , t dk ),0) ?(data,t se );synch:=1 −−−−−−−−−−→ ((x dk , t dk ),0) !(DataToDisc,t se ) −−−−−−−−→ ((x se , t se ), e se ) the order of the different operations expressed by the rules. The first rule covers arrow 1 in Figure 16.5a and b. The second and third rules correspond to arrows 3 (on the receiving part) and 4 in Figure 16.5a and b. In order to clarify, we present here the first rule in detail. The premises of this rule are: the synch variable has value “1,” the flag variable has value “1,” and we have an external transition function (δ ext ) for the DSI. This rule expresses the following actions of the discrete simulator inter- face (DSI): • Receiving data from the discrete model. This is an external transition (δ ext ) expressed by ?(DataFromDisc). • Sending data to the continuous simulator interface (CSI) (!DataToCSI). The data sent to the CSI is the output function λ(x dk ,t dk ) and it is possible, in accordance with DEVS formalism, only as a consequence of an internal transition (δ int ). In our case, the output is represented by !(data,t dk+1 (x dk ,t dk )). This transition corresponds to arrow 1 in Fig- ure 16.5a and b. • Switching the simulation context from the discrete to the continuous domain (action expressed by flag:=0). All the other rules presented in this table follow the same format [13]. TABLE 16.3 Operational Semantics for the CSI Nr. Rule 1. synch = 1 ∧flag = 1 ∧ q k = δ ext ((x ck , t ck ),0,x) (x ck , ∞) ?(data,t dk+1 );synch:=0 −−−−−−−−−−−−−→ (x ck , t ck ) !(DataToCont,t a (x dk ,t dk )) −−−−−−−−−−−−−−→ (x ck , t ck ) 2. synch = 0 ∧flag = 0 ∧¬stateevent ∧q k+1 = δ int ((x ck , t ck )) (x ck , t ck ) ?(DataFromCont) −−−−−−−−−−→ (x ck , t ck ) !(data);flag:=1 −−−−−−−−→ (q, t d, k+1 ) 3. synch = 0 ∧flag = 0 ∧ stateevent ∧ q k+1 = δ int (q k ) (x ck , t ck ) ?(DataFromCont) −−−−−−−−−−→ (x ck , t ck ) !(data,t se );flag:=1 −−−−−−−−−−→ (se, t se ) Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 552 2009-10-2 552 Model-Based Design for Embedded Systems 16.7.2 Continuous Simulator Interface The operational semantics for the CSI is given by the set of rules presented in Table 16.3. In these rules, the Data notation refers to the data exchanged between the DSI and the discrete simulator. All the rules presented in Table 16.3 can be explained analogously to the one already illustrated in Section 16.7.1. 16.8 Implementation Stage: CODIS a C/D Co-Simulation Framework In Section 16.4, we proposed a generic methodology, in two stages, for the efficient design of C/D co-simulation tools. These stages are: a generic stage and an implementation stage. The generic stage, divided in four steps, was presented in detail and applied in Sections 16.4.1 through 16.4.4 and Sections 16.6.3 through 16.6.6. This section presents, CODIS [5], a tool for the generation of simula- tion models in more detail. This tool can automatically produce the global simulation model instances for C/D systems simulation using SystemC and Simulink simulators. This is done by generating and providing the interfaces that implement the simulation model layers and building the co-simulation bus. In the development of this framework, the generic steps of the method- ology that we presented in detail in this chapter are “hidden” in different stages of the simulation flow. The “definition of the library elements and the internal architecture of the co-simulation interfaces” step represents the foundation for the generation of the co-simulation library and implicitly for the generation of the co-simulation interfaces. The internal architecture of the interfaces respects the definition of the operational semantics, the distri- bution of the synchronization functionality, as well as the synchronization model. Figure 16.14 gives an overview of the flow of the instance generation in the case of CODIS. The inputs in the flow are the continuous model in Simulink and the discrete model in SystemC which are schematic and textual models, respectively. The output of the flow is the global simulation model (co-simulation model) instance. For Simulink, the interfaces can be parameterized starting with their dia- log box. The user starts by dragging the interfaces from the interface compo- nents library into the model’s window, then parameterizes them, and finally connects them to the inputs and the outputs of the model. Before the sim- ulation, the functionalities of these blocks are loaded by Simulink from the .dll libraries. The parameters of the interfaces are the number of input and output ports, their type, and the number of state events. Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 553 2009-10-2 Generic Methodology for the Design 553 User parameters Generation script Automatic interface generation Parametrized interfaces Link Modified SystemC .lib .lib .dll Simulation library Simulation library SystemC model SystemC model Co-simulation bus Simulink model Simulink model Simulation interface Simulation interface Interface components FIGURE 16.14 Automatic generation of global simulation model instances. (From Gheorghe, L. et al., Formal definition of simulation interfaces in a continuous/discrete co-simulation tool, Proceedings of the 17th IEEE Inter- national Workshop on RSP, Chania, Crete, Greece, pp. 186–192, 2006. With permission.) For SystemC, the interface parameters are: the names, the number and the data type of the discrete model inputs ports and the sampling periods. The interfaces are automatically generated by a script generator that has as input the user-defined parameters. The tool also generates the function sc_main (or modifies the existing sc_main) that connects the interfaces to the user model. The model is compiled and the link editor calls the library from SystemC and a static library (the simulation library in Figure 16.14). 16.9 Conclusion This chapter presented a generic methodology for the design of efficient continuous/discrete co-simulation tools. The methodology can be divided Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 554 2009-10-2 554 Model-Based Design for Embedded Systems into two main stages: (1) a generic stage, defining simulation interface functionality in a conceptual framework when formal methods for the specification and validation are used, and (2) a stage that provides the imple- mentation for the rigorously defined functionality. Given the importance of the co-simulation interfaces, the methodology concentrates on the co- simulation interfaces, their behavior, as well as the synchronization they assure in the global validation of a C/D heterogeneous system. We also present here a formal representation of the functionality of each interface independent of the other. We illustrate the methodology with CODIS, a tool for C/D systems co- simulation. In the development of CODIS, all the steps of the methodology we proposed in this paper are “hidden” in different stages of the simula- tion flow. The “definition of the library elements and the internal architec- ture of the co-simulation interfaces” step represents the foundation for the generation of the co-simulation library and implicitly for the co-simulation interfaces generation. The definition of the operational semantics and the dis- tribution of the synchronization functionality as well as their behavior play an important role at the output flow with the behavior of the co-simulation interfaces and the synchronization model. The “analysis of the simulation tools for the integration in the co-simulation framework” helped choosing the tools that were used for the modeling of the continuous and the discrete simulators while the “implementation of the library elements specific to dif- ferent simulation tools” constitutes the final implementation of the libraries. References 1. R. Alur and D. Dill, Automata for modeling real-time systems, in Proceed- ings of the Seventeenth International Colloquium on Automata, Languages and Programming, Warwick University, England, 1990, Vol. 443, pp. 322–335. 2. G. Behrmann, A. David, and K. Larsen, A tutorial on UPPAAL, Real-Time Systems Symposium, Miami, FL, 2005. 3. J. Bengtsson and W. Yi, Timed automata: Semantics, algorithms and tools, Uppsala University, Uppsala, Denmark, 1996. 4. J S. Bolduc and H. Vangheluwe, The modelling and simulation pack- age PythonDEVS for classical hierarchical DEVS. MSDL technical report MSDL-TR-2001-01, McGill University, Montreal, Quebec, Canada, June 2001. 5. F. Bouchhima, G. Nicolescu, M. Aboulhamid, and M. Abid, Generic discrete–continuous simulation model for accurate validation in hetero- geneous systems design, Microelectronics Journal, 38, 2007, 805–815. Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 555 2009-10-2 Generic Methodology for the Design 555 6. C. G. Cassandras, Discrete Event Systems: Modeling and Performance Anal- ysis, Richard Irwin, New York, 1993. 7. F. E. Cellier, Combined continuous/discrete system simulation languages—usefulness, experiences and future development, Methodol- ogy in Systems Modelling and Simulation. North-Holland, Amsterdam, the Netherlands, 1979, pp. 201–220. 8. M. D’Abreu and G. Wainer, M/CD++: Modeling continuous systems using Modelica and DEVS, in Proceedings of the IEEE International Sym- posium of MASCOTS’05, Atlanta, GA, 2005, pp. 229–238. 9. S. Edwards, L. Lavagno, E. Lee, and A. L. Sangiovanni-Vincentelli, Design of embedded systems: Formal models, validation, and synthesis, Proceedings of the IEEE, 85, 1997, 366–390. 10. P. Frey and D. O’Riordan, Verilog-AMS: Mixed-signal simulation and cross domain connect modules, in Proceedings BMAS International Work- shop, Orlando, FL, 2000, pp. 103–108. 11. H. R. Ghasemi and Z. Navabi, An effective VHDL-AMS simulation algo- rithm with event, in International Conference on VLSI Design, Kolkata, India, 2005, pp. 762–767. 12. L. Gheorghe, F. Bouchhima, G. Nicolescu, and H. Boucheneb, For- mal definition of simulation interfaces in a continuous/discrete co- simulation tool, in Proceedings of the 17th IEEE International Workshop on RSP, Chania, Crete, Greece, 2006, pp. 186–192. 13. L. Gheorghe, F. Bouchhima, G. Nicolescu, and H. Boucheneb, Semantics for model-based validation of continuous/discrete systems, in Proceed- ings of the DATE, Munich, Germany, 2008, pp. 498–503. 14. N. Giambiasi, J L. Paillet, and F. Chane, From timed automata to DEVS, in Proceedings of the 2003 Winter Simulation Conference, New Orleans, LA, 2003. 15. IEEE Standard VHDL Analog and Mixed-Signal Extensions (1999), IEEE Std 1076.1-1999 16. International Technology Roadmap for Semiconductor Design. [Online]. Available at: http://public.itrs.net/ 17. A. Jantsch and I. Sander, Models of computation and languages for embedded system design, IEE Proceedings Computers and Digital Tech- niques, 152, 2005,114–129. [...]... Although not formally described as such, it in fact functions as such In fact, simulink works with stateflow to accomplish a limited form of hierarchical heterogeneity through this S-function interface We will describe an abstract semantics that is similar to that of Simulink, but 564 Model-Based Design for Embedded Systems simpler It is the one realized in the Ptolemy II framework for actor-oriented design. .. such time is a tick of the SR clock) The SR model is an abstraction of the DE model 570 Model-Based Design for Embedded Systems Since for DE we want to measure the passage of time, the tag set T = N that we used for SR becomes inadequate A first attempt at a denotational semantics would simply use real numbers for time increments between ticks of the clock Specifically, we would replace the tag set... that subsystems can be modeled using any of the three semantics, and these subsystem models can be combined hierarchically to form a whole system We leverage the idea of an actor abstract semantics [33] to provide a coherent and rigorous meaning for 559 560 Model-Based Design for Embedded Systems the heterogeneous system Our approach also provides improvements to conventional DE and CT semantics by leveraging... superdense time, allowing us to use the same model of time that we used with DE This is useful for modeling hybrid systems, which combine continuous dynamics given in Figure 17.7 with discrete mode transitions given in Figure 17.6 In fact, for the tags at which these discrete mode 574 Model-Based Design for Embedded Systems CT director XY plotter Expression 1 Integrator 1 Sigma*(x2 – x1) Expression 2... comparing the form of a Taylor expansion of x with Equation 17.1 The first order RK method, also called the forward Euler method, has the (much simpler) form ˙ x(tn ) = x(tn−1 ) + hn x(tn−1 ) (17.2) This method is conceptually important but not recommended for practical usage for simulating physical applications More practical RK methods have k = 3 or 4, and also control the step size for each integration... interacts with its environment The interface includes ports that represent points of communication for an actor, and parameters that are used to configure the operation of an actor Often, parameter values are part of the a priori configuration of an actor and do not change when a model is 562 Model-Based Design for Embedded Systems SR director Ramp Frequency : 440 Phase : 0.0 Sampling frequency : 8000 External...556 Model-Based Design for Embedded Systems 18 A Jantsch, Modeling Embedded Systems and SoCs—Concurrency and Time in Models of Computation Systems on Silicon Morgan Kaufmann Publishers, San Francisco, CA, June 2003 19 T G Kim, DEVSim++... methods of the receiver interface 566 Model-Based Design for Embedded Systems invoked, the director must manage the execution of the inside model so that input data (if any) are read, and output data are produced When postfire is invoked, the director must update the state of the inside actors by invoking their postfire methods Obviously, directors must be carefully designed to obey the actor abstract... realize that the syntactic structure of an actor-oriented design says little about the semantics The semantics is largely orthogonal to the syntax, and is determined by an MoC The model of computation might give operational rules for executing a model These rules determine when actors perform internal computation, update their internal state, and perform Mixed Continuous and Discrete Systems 563 external... asynchronous models based on variants of dataflow and timed DE models The concept was picked up for hardware design in SystemC (version 2.0 and higher) [45], on which some researchers have specifically built heterogeneous design frameworks [26] Metropolis [22] introduced communication refinement as a mechanism for specializing a general MoC in domain-specific ways, and also introduced quantity managers . t se ) Nicolescu /Model-Based Design for Embedded Systems 67842_C016 Finals Page 552 2009-10-2 552 Model-Based Design for Embedded Systems 16.7.2 Continuous Simulator Interface The operational semantics for. 2005,114–129. Nicolescu /Model-Based Design for Embedded Systems 67842_C016 Finals Page 556 2009-10-2 556 Model-Based Design for Embedded Systems 18. A. Jantsch, Modeling Embedded Systems and SoCs—Concurrency. but Nicolescu /Model-Based Design for Embedded Systems 67842_C017 Finals Page 564 2009-10-2 564 Model-Based Design for Embedded Systems simpler. It is the one realized in the Ptolemy II framework for actor-oriented design. In