【導(dǎo)讀】單片機(jī)類畢業(yè)論文設(shè)計(jì)。河南科技大學(xué)本科畢業(yè)設(shè)計(jì)（論文）

　　

【正文】 he GME metamodelling language, called MetaGME, and is based on Unified Modelling Language (UML) class diagrams and Object Constraint Language (OCL) constraints. A defined metamodel contains all the syntactic, semantic, and presentation information regarding the ASyMod domain – ., which HW and SW concepts can be used to construct models, the relationships that may exist among those concepts, how the concepts may be anized and viewed by the modeller, and the rules governing the construction of models [35]. The second part of ASyMod is a model interpreter that parses the information from the graphical model into a textual description. The obtained description plies with the simulation kernel. This kernel is the third part of the ASyMod tool。 it is based on a methodology presented in [6] and provides the means for the temporal simulation of distributed systems on the system level. The simulation of the model provides temporal information about the SW task executions, the HW resource usage, the contentions on the munication devices and their impact on the task executions. The results are summarized in a HW resource utilization table and statistical information about the execution time (delays, jitter) for each task. Based on this information, the designers can see how the HW and SW ponents interact and ident ify eventual bottlenecks in the system. The ASyMod tool can evaluate several different HW architectures and SW implementations against the design constraints. It enables quick and efficient designspace exploration in the early stages of the design process. The tool can be used as in standalone form or incorporated into the system design toolchain by means of importing an abstract system model and exporting the modelevaluation results in the XML (Extensible Markup Language) format. 河南科技大學(xué)本科畢業(yè)設(shè)計(jì)（論文） 14 . ASyMod metamodel Embedded systems in ASyMod are presented in three aspects (SW functionality, HW architecture, and mapping). Each of these aspects is defined by the ASyMod metamodel and each aspect can be represented by a suitable graph. A simplified metamodel is presented in Fig. 3. The elements visible in each aspect are denoted with dashed lines. An eventflow graph (EFG) is a directed graph that represents an event dependency between the elements, where the graph nodes represent eventdependent elements and the graph edges represent event paths. The nodes can produce and consume events. An architecture graph (AG) is a graph that represents a basic architectural topology and where the graph nodes represent architectural ponents and the edges represent connections between the architectural ponents. A mapping graph (MG) is a directed graph that defines which functionality will be executed 河南科技大學(xué)本科畢業(yè)設(shè)計(jì)（論文） 15 on a particular architectural ponent. Model A in ASyMod can be presented as a set A(FG, AG, MG), where FG is an EFG that represents the SW functionality aspect of the ASyMod model, AG is an AG that represents the HW architecture aspect of the ASyMod model and MG is an MG that represents the mapping aspect of the ASyMod model. . Eventflow graph in ASyMod In ASyMod the SW model is presented within the functionality aspect with an EFG graph. The EFG FG can be expressed as a triple FG(S, TA, Xs), where S={sA1, . . . , sAn} is a set of periodic event generators (PEG), TA={tA1, . . . , tAn} is a set of tasks and Xs = {xs1, . . . , xsn} is a set of connections that define the event flow. The tasks and PEGs represent the nodes of the EFG and the connections represent its edges. PEGs periodically generate events and they can be expressed with the pair sAn (STAn, SDAn ), where STAn defines the period of events and SDAn is the initial delay of the first event. PEGs can also be used for 河南科技大學(xué)本科畢業(yè)設(shè)計(jì)（論文） 16 generating onetime events. In this case, a very long period STAn should be set (beyond the total simulation time) and the delay SDAn is used to define when an event should be generated. The ASyMod tasks are eventtriggered tasks. An ASyMod task is posed of a description of the HW resource usage for a particular piece of the code and RT execution constraints for the deadline and priority. The task can be expressed with a triple tAn (DAn , LAn , BAn ), where DAn is the task deadline, LAn is the task priority and the boolean BAn defines whether the scheduler should be called at the end of the task execution. This is discussed in more detail in Subsection with a guideline (v). The task execution can begin if the task is triggered with an event and if the scheduler, based on the scheduling policy and task RT execution constraints, allows its execution. After the task execution is finished, the task generates an event. The task can be triggered by a PEG or by an event generated at the end of the execution of some other task. The connections in a set Xs? ((TA TA) ∪ (S TA)) define the event flow. Events can be produced by PEGs and by tasks and consumed only by tasks. Each connection is defined with the pair xsn(ym, tAn ), where ym defines the event producer (task tAm or PEG xsm) and tAn is the event consumer task. If a task is triggered by another task, this can be recognized as a sequence of tasks. The period of their execution depends on the PEG that triggers the first task in this sequence. Depending on this PEG, the tasks in the sequence can be one ktime or periodically triggered. . Architecture graph in ASyMod In ASyMod the HW architecture is defined with a concept of abstract execution units and abstract munication units and information about how these ponents are connected together. The HW ponents that perform some data putation (., processors, multipliers, filters, etc.) are modelled as execution units, while the ponents that perform data transfer and storage (memories, buses, channels) are m