voros 5..49 - CiteSeerX

Design Automation for Embedded Systems, 8, 5^49, 2003. 2003 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.

Hardware/Software Co-Design of Complex Embedded Systems An Approach Using Efficient Process Models, Multiple Formalism Specification and Validation via Co-Simulation NIKOLAOS S.VOROS INTRACOM S.A., HellinicTelecommunications and Electronics Industry, Greece (former researcher of Dept. of Electrical Engineering, University of Patras, Greece) LUIS SAŁNCHEZ Dept. Ingenier|¤ aTelema¤tica, Universidad Carlos III de Madrid, Spain ALEJANDRO ALONSO Dept. Ingenier|¤ a de SistemasTelema¤ticos, Universidad Polite¤cnica de Madrid, Spain

[email protected]

[email protected]

[email protected]

ALEXIOS N. BIRBAS Dept. of Electrical Engineering, University of Patras, Greece

[email protected]

MICHAEL BIRBAS Dept. of Electrical Engineering, University of Patras, Greece

[email protected]

AHMED JERRAYA TIMA/INPG, France

[email protected]

Abstract. This paper presents a hardware/software co-design approach where different specification languages can be used in parallel, allowing effective system co-modeling. The proposed methodology introduces a process model that extends the traditional spiral model so as to reflect the design needs of modern embedded systems. The methodology is supported by an advanced toolset that allows co-modeling and co-simulation using SDL, Statecharts and MATRIXX, and interactive hardware/software partitioning. The effectiveness of the proposed approach is exhibited through two application examples: the design of a car window lift mechanism, and the design of a MAC layer protocol for wireless ATM networks. Keywords: Co-design process models, co-modeling, embedded systems, hardware/software co-design, multiple specification formalisms.

1.

Introduction

During the last years, embedded system engineers have come across significant changes in system design due to the increasing complexity of the systems. Fault tolerance and reliability are additional system requirements that must also be taken into consideration during system design. In parallel,the development times of such systems must be reduced in order to shorten time-to-market without increasing the cost of development.To fulfill the aforementioned requirements, system engineering calls for methodologies and tools that will

6

VOROS ETAL.

enable the production of highly complex embedded systems, with shorter development times and reduced cost. Significant research activity is currently taking place in the area of hardware/software co-design, in order to cope withthe design problems of modern embedded systems. As part of this research activity,this paper introduces a hardware/software co-design methodology focusing on the following aspects of system design:

Use of multiple specification formalisms during early design stages. The goal of this point is twofold: (a) to allow the designer to use the formalism(s) that describe his application more accurately, and (b) to take advantage of existing components that are not necessarily described in the formalism currently used for system development.The quality of the overall system is expected to be improved through early co-simulation of the different system parts, even if they are described using different specification formalisms.

Efficient hardware/software partitioning that takes advantage of the formalisms used for describing the model of the system under design.

An innovative methodology that takes into account the needs of modern systems for shorter time-to-market, reduced cost and increased quality.

The rest of the paper is structured as follows:Section 2 presents an overview on the stateof-the-art in the area of embedded systems; Sections 3 and 4 outline the proposed methodology and explain its primitives, and Section 5 delineates the toolset that supports the COMITYmethodology; finally, Section 6 presents the proposed methodology in practice through two case studies; the design of car window lift mechanism, and the design of a MAC layer protocol for wireless ATM networks.

2.

State of the Art in Embedded System Design

During the last years there has been a lot of activity around embedded system design.This has been caused mainly for two reasons. First, the development of electronic technology allows the integration of increasingly complex systems on a single chip.This has risen the need for new techniques and tools to cope with the complexity of modern designs. Second, the market pressure demands for shorter development times and cost effective designs. The net result is significant research activity in the area of embedded systems, and especially in field of hardware^software co-design. The design of systems that have been developed by the different hardware^software co-design approaches have revealed innovations in several design aspects: specification, estimation, partitioning, prototyping, cosimulation, etc. Nevertheless, most approaches support specification languages that are either fixed or not widely used or inadequate for system level specification. The methodological support is limited to the description of the design phases and the tools that should be used in each phase, while continuous subsystems are not supported by most methodologies.

HARDWARE/SOFTWARE CO-DESIGN OF COMPLEX EMBEDDED SYSTEMS

7

In the rest of this section we present an overview of the current trends in electronic system design, and the hardware^software co-design approaches used in academia and industry.

2.1.

Current Trends in Electronic System Design

Among the main current research activities we could cite methodological support, multiformalism specification, hard real-time analysis and design reuse. Methodological support is required due to the complexity of modern systems,where not only powerful tools are needed, but also the methodologies that guide the design process. The methodological support to the design process can be conceived from various points of view. This means that the methodology should define the global strategy to follow in the development of a system, the different design phases considered and the criteria to move from one phase to the next in the design process. The need for multi-formalism specification stems form the fact that complex embedded systems are composed of different components with different specification requirements: analog vs. discrete, software vs. hardware, electronic vs. mechanic vs. hydraulic, control dominated vs. data dominated, real time requirements, safety critical systems, etc. There is no perfect language that it is suitable for any kind of system.Therefore, the most suitable language should be used for each component. Another typical situation in which it is possible to find multi-formalism descriptions is when a system is being developed by different teams of designers with different backgrounds. Finally, another cause of multi-formalism descriptions is the reuse of previously existing descriptions, which can be available in different specification languages. In addition to their complexity, most embedded systems often have to meet hard realtime requirements. To cope with these hard real-time requirements, the design of such systems should incorporate real-time techniques like rate-monotonic analysis. Several hardware^software co-design approaches [13] are now incorporating rate-monotonic analysis to evaluate the timing requirements of the design. Design reuse [14]^[16] is a key issue for the design and development of reliable systems. It is expected to be one of the key points to reduce the development time of complex ICs. Despite the trends in the area of embedded systems and the variety of design techniques, experience has taught designers that there is no perfect design technique for system development. In many cases, existing design environments provide advanced solutions that are not adequate for the design of complex systems. Several requirements can be identified in this context: (1) support for standard or widely used specification languages, (2) support for different application domains, and (3) methodological support for the overall design process. Additionally, most co-design environments focus on digital electronic systems, despite the fact that there are cases of embedded systems that contain parts for controlling continuous subsystems. An example of an application belonging in this category is a system that controls electronically the windows’ lift in car. For this kind of applications, it is necessary to give some support to the combined description of discrete and analog components at least at the specification level, including co-simulation. Moreover, there is a growing

8

VOROS ETAL.

interest in the use of analog electronic subsystems (for instance, all the activities undergoing around VHDL-AMS). Therefore, there is a need for a design environment that provides support for integrated analog/discrete systems.

2.2.

Hardware ^ Software Co-Design

The different hardware^software co-design approaches that can be found in the literature make use of a wide range of specification languages; several approaches make use of implementation oriented languages similar to C orVHDL. For instance,the COSYMA system [5] uses C X , an extension to C to support tasks, timing information and communications. There are also approaches that use state oriented specification languages. One of them is Specsyn [6], a co-design tool developed at the University of California at Irvine. The specification in Specsyn is based on a special language named SpecCharts.This language combines hierarchical state machines withVHDL for the description of the behavior at the lower level in the state hierarchy. Other approaches make use of high-level specification languages, like the approach developed in the context of the ESPRIT COBRA project for the specification language LOTOS [7]. The Ptolemy project [8] aims at the modeling, simulation and code generation of reactive and embedded systems, providing high-level support for signal processing, communications, and real-time control. It makes use of multiple formalisms that have been developed in the frame of the project. The TOSCA system [11] employs multi-formalism specifications. It supports C and VHDL for components preassigned to software or hardware and SpeedCharts and OCCAM for components not preassigned. Finally,C based system descriptions for both hardware and software are promoted from initiatives like SystemC [12]. The latter, promotes a standard where C++ is used both as a standard language for system specifications and as a common platform for model exchange between different tools.

2.3. The Industrial Practice The companies involved in embedded system design have usually in-house design methods and practices and use specific languages for system design. In most cases, industrial design practices usually involve co-design flows reflecting the background experience of each company. In the next paragraphs,we present the basic design steps currently used for the design of real world applications. An embedded system design that encompasses both hardware and software, starts with an informal system specification which is usually written as a document that describes high-level aspects of the system.These informal system descriptions are formalized during the next steps of the design process. The formal system specification is carried out using appropriate formal specification languages based on the requirements posed by the informal specification. It is also a


9

Heterogeneous Specification

SW Model Codesign

Final System

HW Model

Figure 1. Heterogeneous model for system co-specification.

common practice to employ multiple formalisms for describing different parts of the same application.This is either due to the suitability of a specific formalism to accommodate the efficient description of certain parts, or due to the necessity to reuse existing components. The use of more than one formalisms is a bottleneck in the design process since there is usually no direct connection among the different formalisms used. The architecture exploration and system partitioning phase are mainly based on the engineering experience of the designer, and employ informal system specification (e.g., block diagrams) of the system as input. The final system architecture emerges as the result of several successive trial and error iterations of this step.The use of informal specifications usually implies either lack of formal specifications, or bad abstraction level for the latter (not purely functional but implementation specific).The problem remains even in the case of having formal specifications available; if more than one independent specification language is involved for describing system models, they are usually independent among each other. Concurrent (and almost independent) hardware and software development is the next design-step. During this stage, concurrent design of hardware and software modules takes place as delineated in Figure 1. The interaction required between the hardware and software design teams is achieved through informal system specifications. Nothing ensures the lack of inconsistencies and misunderstandings between the hardware and software engineers, as there is not a unified functional system representation and a systematic way for solving concurrent engineering problems. The development of hardware modules takes place involving simulation using HDLs (Hardware Description Languages) and synthesis using commercial tools. Regarding the software components, they are described in a formal description language and then translated to C (or other implementation language). The next step is software development using algorithmic simulation of the software parts using compilers, assemblers, etc. Driver development and verification of their functionality takes also place through the use of instruction set simulators, extended with the required dummy hardware models [17]. The ultimate goal of this hardware^software codevelopment stage is to produce a design where both software running on a specific microprocessor, and system’s dedicated hardware are offered as a system on a chip. CoWare [18]

10

VOROS ETAL.

and Seamless [19] are typical co-design tools used in industry for hardware/software cosimulation and co-verification. The system description is given in VHDL or Verilog for hardware and C for software. Both of them allow co-simulation between hardware and software at the same abstraction level.

2.4. The Proposed Approach The methodology proposed in this paper attempts to identify and improve points that delimit existing co-design practices. The use of more than one specification languages is a key point for reuse of existing components, even if they are described in different languages. Additionally, co-modeling allows the design of hybrid systems where the use of more than one specification languages can lead to more effective system designs.1 As far as system partitioning is concerned, the proposed approach introduces the concept of interactive partitioning and automatic C and VHDL generation for the hardware and the software components respectively. System partitioning takes place as soon as a fully functional model of the system under design is available. In that way, every critical parameter of the system is taken into consideration while the step of hardware/software integration is fully automated. Reuse of existing components, efficient description of subsystems using the appropriate specification language, interactive partitioning and automatic code generation is expected to reduce the time-to-market for the final product, without sacrificing the product quality.

3. COMITY: A Co-Design Methodology for Developing Complex Embedded Systems The purpose of this section is to describe a methodology named COMITY: CO-design Methodology and Integrated Tools for embedded sYstems [9], [10]. The key aspects on which COMITYmethodology focuses on are:

The use of multiple formalisms for system specification, allowing co-modeling of the various subsystems in a seamless way.

Efficient system partitioning.

Prototyping and testing supported by tools: the use of tools associated to different notations makes it possible to generate prototypes that can be evaluated in order to assess the correctness of the approach.

3.1.

Methodology and Process Model

The goal of a methodology is to define how to navigate within the product development phases:


11

Cumulative Cost

I. Determine Objectives, Alternatives, Constraints

II. Evaluate Alternatives, Identify, Resolve Risks

Risk Analysis Risk Analysis Risk Analysis Initial Concept

Prot. 3

Prot. 2

Prot. 1 Simulations, Models, Benchmarks

Reqs. Plan Concept of Life-Cycle Plan Operation Requirements Design Integration & Test Plan IV. Plan Next Phases

Validation Validation

III. Develop, Verify Next-Level Product

Figure 2. Spiral model.

Which Activities to Perform: Determine data or control information, identify subsystem and components.

How to Represent the Phase Products: Notations, tools, etc.

The proposed methodology is appropriate for being used in conjunction with advanced process models.The process in an engineering project can be defined as the approach taken in the development of the product. The process model is the strategy to follow in the development of a system. In particular, it provides a framework for determining the order of the stages or phases involved in embedded system design, and establishes the transition criteria between them. The ultimate goal of a process model is to guide the development activities in order to finish the system on time,within the assigned budget and meeting the functional and non-functional requirements. A suitable approach is the spiral model [20], which is based on risk-analysis techniques and the evolutionary development of the product. The activities in the development are oriented towards reducing risks in the development process.The spiral model depicted in Figure 2 is a risk-driven process model and it is well suited for the mentioned goals. The term risk-driven process model refers to a process model in which each stage in the development of the system under design attempts to minimize the risks involved in it. These risks often come from uncertainties of the results obtained when taking different design

12

VOROS ETAL.

decisions. As it is explained below, the management of these risks is attacked usually by means of simulation. The approach proposed in the this paper is consistent with the concepts of the risk-driven process model; the different system parts are described using multiple formalisms for system specification, and the validation of the system under design is achieved via co-simulation at the various development stages. Graphically, the process model can be seen as a spiral where the angular dimension represents the progress made in completing each cycle and the radial dimension represents the cumulative cost incurred in accomplishing the steps to date. In each cycle of the spiral model one portion of the system under design is developed.This does not need to represent exactly one of the methodological phases presented in Section 3.2. What usually happens in practice is that one methodological phase consumes several cycles of the spiral. For instance, we can imagine that if we develop a model of a system that uses both SDL and Statecharts,the SDL model can be produced in one or more cycles of the spiral (depending on the size of the model) and the same happens for the Statecharts model. Each cycle of the spiral is divided in, at least, three parts: (1) identification of the objectives of the portion of the product being elaborated for this cycle, (2) the alternative ways of implementing that portion and (3) the constraints on the application of the alternatives. The next step in each cycle implies the evaluation of the alternatives relative to the objectives and constraints previously identified. Frequently, this process will recognize areas of uncertainty that are sources of project risk. One of the most common ways of handling these risks is the development of system prototypes, so as to check the suitability of a particular approach. Usually, the product developed in a spiral cycle is one or a set of possible refinements of previous development states.The tools supporting the corresponding formalism should allow model execution or animation, whose output will be used to check the appropriateness of the proposed solution or to assess the relative merits of the evaluated alternatives.The latest steps complete each cycle of the spiral with a review that covers all products developed during the previous cycle, including the plans for the next one and the resources to carry them out. The plans for the following cycles may also include a partition of the product into subproducts or components to be developed in parallel by individual teams. For each of these sub-products or components, parallel spiral cycles guide the development process.

3.2.

Methodological Phases

The next sections describe the main methodological phases defined in the context of COMITYmethodology.

3.2.1.

Requirements Capture and Specification

The objective of this initial phase is to obtain as much information as possible about the requirements of the system.The requirements should state what the system has to do.These are not just functional requirements but also non-functional ones. Non-functional requirements can refer both to the system under design or to any other architectural, company


13

dependent or whatever prerequisites that may limit or directly influence the design of the product. This kind of information will lead or help the designer in making the decisions required during this phase. Nevertheless, it is expected that in any minimally complex design the initial needs will evolve or change along the process, or some unforeseen issues may arise, so it will eventually be necessary to come back to the requirements capture and update the documentation accordingly. The tasks to be completed in this phase are independent of the notation or the design flow that may be chosen.The requirements should be stated as clearly as possible, and interrelations or dependencies among them should be highlighted. Usually no specification language is used for the requirements document. The common procedure is to write it, informally, in English. For example, Sections 6.1.1 and 6.2.1 describe in plain English the initial requirements of each case study (no specification formalisms are involved). Naturally, at this stage the users may decide to use any tool like editors, version managers, graphical animation, etc.

3.2.2.

System Architecture Design

At this stage,the system,whose requirements are already available, is to be designed. In the context of COMITY methodology, these models can make use of a multi-formalism approach. The system is partitioned into subsystems, each of which can be described in a different formalism.

3.2.2.1. Identification of Main Components and the Notations The identification of the subsystems and the assignment of the corresponding notation are not straightforward. It can be that a preconceived idea of the design that influences the chosen notation and tools, or that a somehow required set of tools and notations determines the subsystems in which the design is split. The final strategy recommended in the method is a mixture of both approaches. It has to be taken into account that the method and toolset aims to be as general as possible, so that it can be tailored to different types of users and systems.The methodology toolset supports in fact a set of subsets of notations. The viable combinations of notations depend on the possible design flows or at least co-simulation facilities available for the selected subset. For instance, no co-modeling or co-simulation tool is able to deal with a system composed of components using the three formalisms presented in Section 3.3.Therefore, the first rule of use is to choose a set of formalisms for which there is tool support. The application domain will also influence the notation chosen, because each formalism is suited for some particular characteristics of the systems, which may appear more often in some application domains.

3.2.2.2. Information Exchange Between Subsystems The second aspectthatcomes into consideration inthe architecturaldesignphase,after the identificationofcomponents,isthe

14

VOROS ETAL.

informationexchangebetweenthesubsystemsdescribedindifferentformalisms.Thelogical informationthat needs tobe exchanged consists of data and control information.This phase hasto define the mapping betweenthe logical information and the specific constructs inthe selected notations.

3.2.2.3. Model Validation The final sub-phase in the system architecture design is the initial validation of the design. At this level, the design description is a logical model, in which system resources are not considered. At this stage, it is possible to validate that the model fulfills system requirements, and that these are complete and consistent. In addition, it is also possible to make an initial evaluation of the subsystem cohesion and coupling, and estimate the communication overhead. Being a logical model, it is not possible to validate other requirements, such as very detailed functionality, timing, cost, performance, etc. Finally, validation of the notational decisions is also required, not only as far as their interfaces and external relations are concerned, but also to see if the internal characteristics of the subsystem match the descriptive capabilities of the notation. Finally, this initial validation sub-phase should address the task of defining black box test cases based on the use of the system.

3.2.3.

Co-Modeling and Detailed Design

This phase should undertake the refinement of the previously identified components. It is very important in doing so to bear in mind the restrictions imposed in each case on the interface by the other components in the system.That is, they have to comply with the information exchange schema defined in the previous phase. Special care has to be taken if the detailed design of a component is used as an input to a co-modeling tool, because co-modeling is based on translation of whole components from one notation to the other, and severe restrictions are imposed on the sub-language covered by the translator.

3.2.4.

Model Partitioning

The design is already detailed enough in this phase, and the next step is to partition it into software modules running on different processors or hardware/software modules. As a result, a virtual prototype emerges prior to the final implementation. The resulting prototype at this point,takes into account hardware resources as well.It has been decided which modules will be implemented as software running in processors or as hardware.Atthis stage,it is possible to make an initial evaluationofadditional requirements such as the time response of the system, performance, hardware costs, communication overhead, etc. For this purpose, it is possible to use tools such as model animators, emulators, hardware simulators, etc. The constituent parts of the virtual prototype are software modules of the systems described in a programming language like C, and hardware parts of the systems that


15

are described in a hardware description language. In the case of hardware^software partitioning, to bridge the communication gap between hardware and software, an additional module is required that will enable the hardware signals to be realized by software and vice versa.The output of this phase is a virtual prototype that reflects the final partitioning scheme and fulfills the functional and non-functional constraints posed by the system requirements.

3.2.5. Targetingand Implementation The final system implementation is the next step following a successful system partitioning. The final C code must be generated taking into account the operating system on which the software part will run. Operating system selection is critical in embedded system design since it must fulfill requirements such as real-time features, specialized scheduling policies, multiple threads, etc., in a reasonably small kernel. Additionally, it must contain primitives that will ease the communication between hardware and software. Concerning the hardware part,theVHDL code will be transferred to silicon following the traditional hardware fabrication process.

3.3.

Specification Formalisms Supported

One of the main advantages of the methodology presented in the previous section is that supports a set of different specification formalisms, covering a wide area of embedded applications belonging to different domains like telecommunications [21], automotive [22] and aerospace [25]. In this way, the designer has at his disposal a set of different candidate notations along with RAD (Rapid Application Development) tools that support hierarchical design according to the spiral model of Figure 2. The possibility of modeling the system using a multi-notation approach has several advantages including:

Use of the Most Suitable Notation for a Given Part of the System. The selection of the notation depends on the technical culture of the industry or domain area, the characteristics and functionality of the subsystem and the facilities provided by the tool supporting the notation.

Design of Hybrid Systems. Different notations can be used for the discrete and continuous parts. Appropriate means are provided for their interconnection in order to enable model checking by simulation, partitioning and code generation.

The formalisms supported by the proposed methodology are shortly described in the following paragraphs.

16

VOROS ETAL.

3.3.1.

StateCharts

This notation [28] is used to model real-time reactive systems that are centralized (without communication or synchronization) and have a static architecture (without dynamic task creation). It has a graphical language and good facilities to model abstraction and hierarchy.

3.3.2.

SDL

SDL (Specification and Description Language) [29] is used to model distributed soft realtime systems in which the communication aspect is significant. In contrast to StateCharts, it allows dynamic creation and deletion of processes enabling it to describe dynamic networks of communicating processes. It has also a graphical language, but it does not have the state hierarchy of StateCharts nor does it allow the specification of actions to be performed on entering or exiting a state.

3.3.3.

MATRIXX

The guidelines for use of MATRIXX [30] for modeling are perhaps the easiest to define. It is the only available formalism in the set of tools supporting the methodology that describes continuous behavior, so if that is the case of the subsystem under consideration, the selection is clear. It is data-driven, with periodic parts also and an underlying periodic simulation schema. Event-driven parts can also be defined by means of triggered blocks. It has also a hierarchical structure.

4.

Selection of a Suitable Notation

The goal of this section is to provide some basic notions on how to select the most suitable notation for a given component. For this purpose, it is necessary to take into account the development context and the characteristics of the components to develop.

4.1.

Development Context Criteria

When discussing the selection of the most appropriate notation for a given subsystem, it is important to first draw attention to certain factors which may play a crucial role in influencing this choice but which are not intrinsic to the architectural design itself, rather to the context in which it is developed. Before mentioning some such factors we observe that they may intervene even earlier in the design process, in that the decomposition itself may also be influenced, by a preconceived idea of which formalisms are to be used.


17

Some of the main ‘‘contextual’’ factors that may influence the choice of notation (and prior to this, perhaps also the architectural decomposition) are the following:

the desire to capitalize on in-house experience with a particular formalism and probably also with an associated set of tools;

considerations connected with the availability of an associated toolset, or its maturity, power or usability (even user-friendliness);

the desire to reuse existing descriptions in this formalism, and perhaps also other design products derived from them, in order to reduce costs and lead times or in order to conform to standards;

any prior conviction derived from experience and knowledge of the domain, that a certain part of the system will be more effectively modeled, analyzed, tested or implemented using certain formalism.

4.2.

General Selection Criteria Based on System Properties

In this section, it is presented a summary of the general criteria influencing the choice of formalism to be used for a given subsystem (this term is considered to include the case where the subsystem is the whole system) based exclusively on properties of the subsystem and the nature of its interface with the rest of the system and with the system’s environment. This is the result of a study of the different features of the notations and different types of systems [26]. All the notations allow the description of parallel systems. MATRIXX is the only one that can be used when it is necessary to describe a continuous system. Hence, it must be used when dealing with a hybrid system. With respect to discrete systems, the choice depend on additional factors. If the system is asynchronous, both SDL and StateCharts can be used, although the first one is a bit more suitable. StateCharts allow the modeling and simulation of synchronous systems. SDL on the other hand, is a notation defined initially for the description of protocols and communication systems, it is more suitable when dealing with parts specifically related with the interaction between subsystems. This is especially clear when dealing with distributed systems. All three notations can be used for describing time aspects in the development of real-time systems. However, StateCharts are superior in this aspect, as the were defined with this type of systems in mind. MATRIXX and StateCharts are appropriate for dealing with reactive systems, as well as to describe user interfaces. However, this last advantage is very related with the tools that were used. Finally, it’s worth mentioning that the semantics of SDL are precisely defined, when compared to the other formalisms. This feature makes it suitable for high-integrity systems, where very rigorous development procedures are required.

18

VOROS ETAL.

5. The Advanced Toolset The methodology presented in Sections 3 and 4 is supported by a set of tools that provide an efficient technology to design hardware/software systems, based on a multi-formalism specification that allows early validation of the partitioning, supports virtual prototyping via co-simulation, and generates automatically C code for the software components and synthesizableVHDL code for the hardware components. This set of tools is called advanced toolset and supports SDL, Statecharts and MATRIX X diagrams for system specification, and covers the following stages in the methodology: Co-Modeling It is supported by the coupling of SDL-Statecharts and is implemented in ObjectGEODE. Co-Simulation At specification level, MATRIX X is connected to STATEMATE to provide a co-simulation between block diagrams and Statecharts. Two SDL models can be co-executed with ObjectGEODE. Finally, a semantic model for distributed cosimulation that can handle SDL, Statecharts and MATRIXX models together has been developed and validated. Based on this model a co-simulation kernel has been implemented. At the implementation level, a C-VHDL co-simulation can be performed by using the codes generated from MUSIC. Partitioning It is provided by MUSIC and takes as input an SDL specification and transforms it automatically to C and VHDL code. Targeting Targeting, in addition to the generation of C code from the tools ObjectGEODE, MATRIXX and STATEMATE, is also supported by a MUSIC module for both C and VHDL. The synopsis of the advanced toolset is outlined in Figure 3, where the different notations with associated tools and their interactions are presented.

5.1.

Co-ModelingTools

As part of the advanced toolset, co-modeling using SDL and Statecharts is allowed. The approach adopted is based on the assumption that the two notations have some complementary features. StateCharts are used first for conceptual modeling; basically, a StateChart model is a hierarchy of state diagrams.The next step is to transform them into SDL constructs and to derive an architectural model. Finally the latter will be completed in SDL in order to obtain a detailed design model that can be simulated.Therefore we have identified which StateChart constructs must be included in SDL, and how to transform them in standard SDL [27], [35].


19

Co-Modeling Cosimulation ObjectGEODE

ObjectGEODE

SDL

STATEMATE

MATRIXX Block Diagrams

Statecharts Code Generation

Music (Solar)

C

VHDL Synth

Code Generation

C

VHDL Behavior

C

Figure 3. Synopsis of advanced toolset.

A study was carried out showing that uncovered StateChart concepts worth to introduce in SDL (through language extensions) are: macro-states (or nested StateChart) without concurrency, entry actions (with inhibition possible), and exit actions (with inhibition possible). A set of transformation rules between StateChart and SDL, have been derived and the required extensions realized in the ObjectGEODE tool. The main rule that has been followed is: The SDL behavioral model including StateChart constructs can still be simulated with ObjectGEODE.This means that the final simulatable SDL model is a pure SDL model; it has been called the flat model, compared to the original model that includes StateChart extensions which will be called structured model. The designer will produce the structured model and then simulate the flattened model. As a result, if the end user selects to use the combination of SDL^Statecharts for modeling his system, he must follow the following steps: 1. Describe parts of the system using either SDL or StateCharts.

2. Transform the StateChart model into a structured SDL model.

3. Complete the detailed design in SDL.

4. Translate the structured SDL model into pure SDL (by flattening the transitions).

5. Simulate the SDL model.

20

VOROS ETAL.

SDL

SDL

Model Under Test

Test Model Simulation

TCP/IP Communication

User Interface (UI)

Simulation or Code Generation Command Program (CP)

Figure 4. Co-execution of SDLTM and SDL MuT.

In order to use SDL and Statecharts together, there are several restrictions that must be taken into account. More specifically, it is not allowed to employ concurrent activities; if the original StateChart contains such constructs,the model must be split into two separate diagrams. Moreover, no nested states with concurrency are supported; this is a prerequisite to be able to flatten the model. Multiple transitions for one event of a state are not allowed as well; such transitions must be modeled by using a conditional state. Finally, the conditions and the actions must comply with SDL syntax rules. The first two restrictions have an impact on the models, as they may force the user to adapt its model according to the restrictions imposed by the StateCharts subset supported. The last two restrictions are less important because they are more related to the style of modeling used and not to the capabilities of the StateChart formalism. Appendix presents the details for SDL^Statechart transformation.

5.2. 5.2.1.

Co-SimulationTools SDL ^ SDL Co-Execution

The co-execution of two SDL models is realized within ObjectGEODE (see Figure 4). In the proposed approach, one SDL model is theTest Model (TM) and the other is the Model under Test (MuT). The new functionality developed allows the designer to create these models and to execute them in parallel. The TM is simulated with the ObjectGEODE simulator while the MuT is either simulated with the same simulator, or simulated with another simulator, or generated by using the C code generator and executed. The coexecution session is controlled by the SDL simulator, at theTM side. Co-execution terminates when the user stops theTM or the MuT.


5.2.2.

21

MATRIXX ^ STATEMATE Co-Simulation

MATRIXX^STATEMATE co-simulation is achieved through the coupling of the tools during a co-simulation session.The tool coupling is achieved using Plug&Sim [27], [35], a networking-capable integration environment that provides an open interface named CUDOs (Co-simulation Using Distributed Objects) for tool interconnection. In order to perform a MATRIXX^STATEMATE co-simulation the user must: 1. Select the top-level model component (either in MATRIXX or in STATEMATE). 2. For each undefined references in the top-level model component, select a model component from the complementary tool; consistency checking of the model’s input and output is done at this point. 3. Modify the input and output signal routing, or force connections of unmatched signals. 4. Repeat the process of model component selection for any undefined references in the hierarchy. As soon as the end user has finished the above steps, he has to specify the simulation options for each tool that participates in the co-simulation session. Simulation and visualization of the system behavior is done using each component’s native tool.

5.2.3.

Distributed SDL ^ StateChart ^ MATRIXX Co-Simulation

The term co-simulation is used to describe the simulation of a system composed of subsystems specified in one of several different formalisms. This is achieved by using an instance of the appropriate simulation tool for each subsystem together with mechanisms to manage the interaction between these simulator instances.2 The interconnection framework described here can provide the basis for the interconnection of simulators via a generic coupling mechanism.

5.2.3.1. Interconnection Framework Interconnecting subsystems specified using different formalisms inevitably involves the definition of a framework into which must be embedded. Additionally, unambiguous meaning must be given to their interconnection. The main aspects of such a semantic framework (both in the context of a coordinated use and an integrated use) are:

1.

Global timing model and a definition of the relation of the timing models of each formalism to this global timing model;

22

VOROS ETAL.

2.

a common data model, needed to make sense in one formalism of the data from another, covering at least the data types to be interchanged;

3.

the global connectivity, that is, the specification of the communication channels between the different subsystems: which subsystem or (part of a subsystem) is to communicate with which subsystem (or part of a subsystem); the latter is the major part of the global architecture; and

4. globalcommunication mechanisms, defining the structure and semantics ofboththe interfaces offered by the subsystems and the information exchange between them. Point 4 may be considered to include point 3, in particular, if we do not wish to statically specify explicit communication channels between subsystems. All the four aspects are discussed in detail in [26], [27], [35]. Important assumptions retained for the realization of the distributed co-simulation are the followings: 1. Actions in each of the discrete-time formalisms used take zero time. 2. The global time is discrete, and continuous subsystems cannot communicate except under the discrete time scheme. 3. Synchronous and asynchronous behaviors are examined, and the choice must be compatible with the global communication mechanisms. 4. Type equivalence is defined for mapping the data representation in the different formalisms. 5. Finally a generic communication semantics is elaborated to map against the communication mechanisms of each formalism: SDL, Statechart and MATRIXX. All inter-subsystem communications are events, possibly with associated data exchange.

5.2.3.2. Implementation of Co-Simulation MATRIX X is of most interest here as a continuous time simulator. Co-simulation using this simulator is implemented through the use of a User Code Block (UCB) which encapsulates the C code implementing the interface to the rest of the system. All the blocks that communicate with the rest of the system must be connected to this block. Through this C code, the simulator can be instructed to advance to a certain time, at which the next global event is scheduled, or to rollback to a certain time, in the case where an event was generated by another continuous simulator instance or by a synchronous simulator instance. The SDL language has an asynchronous temporal behavior. Co-simulation using ObjectGEODE’s simulator is carried out with a co-simulation backplane playing the role of the SDL environment. By means of this API, a real SDL environment can not only


Interconnection Model

Statecharts

Diff. Equations

Model Part

Model Part

23

SDL

Model Part

Design, Simulation, Realization ... Figure 5. SDL^MATRIXX^Statechart co-simulation.

exchange signals with the simulator, but can also send simulation advance commands to it and receive time progression and other trace information from it. The simulator of STATEMATE allows either synchronous or asynchronous temporal behavior. It provides means to communicate with external world via interface code (communication of this kind is handled as master^slave). In order to achieve communication with an external environment,the API of the simulator should be used, in conjunction with simulator’s primitives required to send commands for controlling the behavior of the simulator. Figure 5 depicts the co-simulation scheme adopted by advanced toolset; the shaded parts refer to modules that have been developed as part of it.

5.3.

PartitioningTools

Harware/software partitioning is achieved using MUSIC.The tool takes as input the SDL model that has been elaborated and produces a new (partitioned) description of the system,the goal of which is to obtain an optimal repartition of the system functions into hardware and software.The latter model is validated through co-simulation,using criteria such as processing time, memory size, implementation cost, constraints imposed by existing target architectures, etc. In the standard way of designing embedded systems, deciding which parts of the system are going to be realized in software and which in hardware, is done at the first design stages. Such an approach usually makes product integration more difficult and implies many iteration cycles before getting the right product.

5.3.1.

SDL System Level SpecificationTransformation

In order to capture the SDL specification in the design environment, MUSIC uses an intermediateformat,namedSOLAR [4].Thisformathasbeendefinedintheobjectiveofsmoothing the transition between the system-level design world and the behavioral synthesis world. SOLAR supports several abstraction levels ranging fromthe system-leveltotheRT-level.

24

VOROS ETAL.

ObjectGEODE

SDL Specification

Graphical User Interface SAS SDL Capture

PARTIF Partitioning

S2CV Behavioral C/VHDL Generation

HL Synthesis Tool Synthesizable VHDL Generation Library

Unified Intermediate Form SOLAR

C Code

Figure 6. MUSIC environment.

Behavioral VHDL

Synthesizable VHDL

Simulation

RTL Synthesis and Simulation

5.3.2. Transformational Partitioning The partitioning within MUSIC, as depicted in Figure 6, is oriented towards systems dominated by control flow. On the other hand, there are systems for system level synthesis for applications dominated by data flow such as Digital Signal Processing (DSP) applications [3].The behavioral partitioning relies upon the operations of cutting and merging of extended finite state machines.The input specification is an extended FSM composed of parallel and sequential machines.The output of the partitioning step is a set of partitions containing the extended finite state machines. The partitioning strategy followed is interactive due to complexity of the systems to be partitioned, and the fact that system partitioning is an NP-complete problem.The decision of not developing an automatic approach has been taken for reasons of realizing reliable estimations at the system level [2] independent of an application domain. The goal is to combine both the manual design with the automatic design. The approach we propose, assumes that the designer begins synthesis with an initial specification of the system functions and an architecture solution. The environment offers to the designer a set of transformation primitives of a specification allowing him to achieve the desired architecture by a set of successive refinements. All the refinement transformations are realized in an automatic manner. This permits a greater acceleration of design cycle. On the other hand, all the refinement decisions


25

are taken by the designer using his know-how and experience to converge towards an efficient solution. A toolbox environment is at the disposal of the designer. It provides the partitioning primitives to manipulate the behavior of the finite state machines, namely: Move, Merge, Split, Flat. The primitive Move serves to displace the FSMs around the hierarchy of an extended finite state machine; the primitive Merge combines the sequential machines into a single machine; the primitive Split cuts a sequential machine to produce several machines in parallel; the primitive Cut transforms a parallel machine into a set of machines either interconnected or communicating; finally,the primitive Flat breaks a hierarchy of a subsystem into a flat net list. The system hierarchy and structure are handled by Flat, Cluster, Merge, Split.The primitive Flat flattens a hierarchical design unit. In other words it eliminates all hierarchical levels inside this object.The primitive Cluster groups a set of design units into a new design unit.This operation works on the structure and adds a new hierarchical level.The primitive Merge realizes a behavioral merge operation.The design unit will be composed of parallel states machines of its behavioral design units. A hierarchical level is suppressed.The primitive Split works on the behavior of a process in order to cut it into a set of independent processes. This environment is called PARTIF [1], and permits to realize a partition by applying the above primitives in a sequence.

5.4. TargetingTools Virtual prototyping is a step to generate executable descriptions, and in our case, the C and VHDL descriptions for each abstract processor resulting from the partitioning step. The generated descriptions can serve for both simulation and synthesis. The output of the virtual prototyping is a heterogeneous architecture composed of virtual software processors (C code) and virtual hardware processors (VHDL code). Figure 7 outlines the generation of the structural VHDL code, while Figure 8 presents how behavioral VHDL descriptions are produced.The codes corresponding to the communication elements which are either the services or the communication controllers are extracted from an implementation library of communication. Once again, depending on the implementation of the communication, respective codes, namely C for software and VHDL for hardware are generated.

6. Case Studies This section outlines the use of the proposed methodology and the advanced toolset in practice. Although the methodology and the advanced toolset support a wide range of systems [21], [22], [25], due to space limitations we present two indicative case studies.The first one describes the development process of a car window lift mechanism; for modeling the system under design SDL, Statecharts and MATRIXX have been employed. The second one describes the development process of a MAC layer protocol for wireless ATM networks; SDL and Statecharts have been used for describing system models.

26

VOROS ETAL.

Solar

VHDL

( Design Unit Entity_name ( View

Architecture_name ( Interface ( Port ... ( Direction In) ( Type ...) )

) ( Contents ( Instance ... ... ) ( Net ... ... ) )

Entity Entity_name is Port ... : in Type ... ; End Entity_name ; Architecture Architecture_name of Component Instance_Name Port (... ) ... Begin Instanciation : Instance_name Port map (... ) ...

Entity_name is

End Architecture_name

) ) Figure 7. Generation of structural VHDL code.

VHDL

Solar ( StateTable ( StateList

Request_Manager init send_receive )

( EntryState

init )

( State init

Request_Manager Type

state_type

( init send_receive ) ;

is

Signal state : state_table := init ; Begin Case

Current_state

When

) ( State

Process

init ...

is

=>

send_receive send_receive

When

...

) )

=>

End End

case ; Process

Figure 8. Generation of behavioral VHDL code.

6.1.

Case Study 1: CarWindow Lift

One of the key points of the COMITYmethodology is to enable system specification using several notations at the same time.This is illustrated by the present case study (a window lift for a car). It makes use of the three notations considered: SDL, Statecharts and MATRIXX in an application of industrial interest.


6.1.1.

27

Overview

Our system is a controller for the lifting of windows in a car. All the windows (4) in a car are controlled.We consider initially a simple system in which every window is controlled by a processor embedded in its corresponding door, without any central controller for the system. Moreover, the buttons that allow users to control the window movement are situated on the doors, having only the driver’s door the possibility of controlling all the electric windows of the car. For this reason it is necessary that the processor embedded in the driver’s door can send commands to the rest of the door processors, and that these processors can receive and execute those commands. For the communication among the different processors of the system we reckon that they are physically connected by means of a CAN bus in the car.Therefore, the final architecture is a distributed system with four processors that communicate by means of a CAN bus.This architecture is predefined due to global car design issues. The window-lift is controlled by ‘‘one-touch’’ buttons.This means that the same button is used both to raise the window and to stop it. So users can decide the movement direction of the windows by pressing (one-touch) the corresponding button. When any window is moving, they must press the button which implies movement in the same direction for that window in order to stop it. In any way, windows should stop automatically when they find any physical obstacle in their movement. Of course, if a window is in its top position, pressing any of its corresponding up buttons should have no effect and, in turn,when a window is in its bottom position, pressing any of its corresponding down buttons should have neither effect. The model of the system also includes the motor of the windows.This allows us to model the actions/reactions between the motor and the controller.The interface between the motor and the controller is as follows. The controller can send three different events to the motor: move up, move down or stop. When the motor receives a move event it starts to move the window in the desired direction until receives a stop event or the window is blocked. The window can be blocked due to two reasons: either it is in its top or bottom position or there is an obstacle on it. When the window is blocked and the motor tries to move it the current that flows in the motor is higher than in normal operation.This can be used to detect blocking.The motor sends an event and a continuous signal to the controller. The event is sent when it is detected that the window is blocked.The signal is the position of the window.

6.1.2.

Case Study Design

This section illustrates the process of design of the case study following the methodological guidelines presented in this paper.

6.1.2.1. Requirements Capture and Specification The goal of this phase is to obtain as much information as possible about the system being designed. The objective is to know what the system has to do, not how it will do what it has to do (this will be attacked in the

28

VOROS ETAL.

next phases). The information should include not only the functional requirements, but also the non-functional ones, like performance and costs. In this example, first we defined the functional requirements of our window lift model.These requirements are basically the global description of the system presented in Section 4.The only non-functional requirements considered in this example are the architecture (4 processors attached to each door plus the CAN bus) and the speed of the window.

6.1.2.2.

1.

System Architecture Design This phase includes the following tasks:

Identification of the Components that will Form the System. Following the architecture defined in the global model of the system, each controller will allow us to have already pre-partitioned the functionality that will be allocated on each door, and we only have to perform the partitioning on each controller component.

2. Selection of the Notation that will be Used for Each Component. The selection of the notation that will be used for each component was done as follows. For the controllers we decided to use Statecharts, because Statecharts is a suitable language to model control oriented systems like the controller.The bus has been modeled using SDL, because SDL is a good specification language for communication related systems.With respect to the model of the motor,we decided to use MATRIXX,because it includes continuous parts, and also because a certain amount of data processing was necessary. 3.

Definition of the Information Exchange Between Subsystems. We decided to split our system in nine components: one controller and one motor on each door plus a model of the CAN bus. In our case, we have two kind of interfaces between the different components: the interface between the controller and the bus and the interface between the controller and the motor. In the case of the bus, the communications are bi-directional to allow the controller either to send messages to the bus or to receive messages from it. The messages are composed of an event that indicates that there is a new message and an associated data value composed of the movement of the window (up or down) plus the identifier of the controller to which the message is sent.With respect to the interface between the controller and the motor, the controller sends three events to the motor: move up, move down or stop. The motor sends an event to the controller (the window is blocked) and a continuous signal with the position of the window.

4. Validation ofthe Architectural DecisionsTaken so Far. In this task we should check that the decisions taken in the previous phases fit within the requirements that have been presented in Section 4. Of course, not all the requirements can be validated at this time.The main check that we can do at this point is to analyze if the decisions taken in points 1 to 3 are reasonable.


L Motor From _M_L

R Motor

To_M_L

From _M_R

L Control WL_To_Bus

29

To_M_R

R Contro l

WL_From_Bus

WR_To_Bus

WR_From_ Bus

Communication Bus R_WL_From_ Bu s

R_WR_From_Bus

LR Control From _M_R L

To_M_R L

RR Control From _M_R R

RL Motor MATRIXX

To_M_R R

RL Motor Statemate

ObjectGEODE (SDL)

Figure 9. High level system description.

Figure 9 shows the global description of the system, after have followed the described steps. It is a high abstraction view, where the main modules are identified, as well as the notations for their description.

6.1.2.3. System Co-Modeling and Detailed Design In this phase several refined versions of the models to be developed in each notation are produced. In each refinement cycle the system is validated via simulation of the model in isolation or co-simulation of the whole system specification.The development of the part of the system in each notation is briefly described in Sections 6.1.3 (SDL part), 6.1.4 (Statechart part) and 6.1.5 (MATRIXX part). With respect to validation, we have simulated the parts developed in each notation to test their functionality. It is important to note that there exist a semantic model for the combination of these three formalisms [39].

6.1.2.4. Hardware/Software Partitioning The design is already detailed enough in this phase, and the next step is to partition it into software modules or software/hardware modules (with MUSIC). After that, code is generated for the software and hardware parts. In this phase, the interface construction between the software and hardware components should also be performed. In this case partitioning affects only the part that should be implemented, that is, the controllers.The motor and the bus models are only needed to model the environment in which the controllers work. An initial partitioning has been already done in the architectural design phase, when we used a different component for the functionality to be allocated in each controller. No additional partitioning seems necessary, as the functionality of the controller seems simple enough to fit in one processor.

30

VOROS ETAL.

6.1.2.5. Targeting and Implementation In this phase the software code is compiled to obtain target processor code, the hardware components are synthesized, and the different components are integrated in the target architecture. Due to space limitation,this phase of the design has not been considered in this case study.

6.1.3.

SDL Subsystem

6.1.3.1. Introduction It was decided that, rather than letting the form of the CAN bus specification be dictated entirely by the system of the case study, instead, the specification would follow the standard as closely as possible, choosing an appropriate level of detail. For this reason, the specification includes the modeling of priorities and arbitration, the mechanisms for this being one of the main defining features of the CAN bus. At the same time, every attempt has been made to define a generic specification, in terms of the number of nodes and the messages to be exchanged.

6.1.3.2. General Concepts The following are specified at the top level as constants and then used throughout the specification:

number of nodes

number of active nodes

number of message types

number of bits for the arbitration field

where the second defines the number of nodes which are emitters as well as receivers.The fourth is defined to be as short as possible rather than sticking to the length of the standard. This will depend on the number of nodes, the number of message types and which nodes can send which message types. The processes modeling the CAN controllers and the bus itself (see below) are entirely independent of the values given to these top-level constants. In order for this to be possible the CAN controllers must be dynamically created at initialization; this being done in the manager process.

6.1.3.3. Interfaces to the SDL Environment Dynamic creation of the controller processes also means that they will not have their own individually named channel to the SDL environment. Since addressing is not accomplished in SDL using ports but either by sending to a named process or along a named channel, this means that another process must mediate between the external CAN users and the CAN controllers. Such a process could either act as a gateway or as a name server; currently, the latter is implemented. As far as incoming messages are concerned, for a controller to receive a message from the


31

SDL environment, the external user must previously have asked the name serverin our case the manager process also fulfills this rolefor the PId of the controller associated to a particular node number. Concerning outgoing messages, as a controller knows its own node number, it sends messages directly to the SDL environment with its node number as a parameter. The only data types used in the interface to the environment in the current specification are integers. The message type is an integer as is the message contents (in the case study itself, the message contents are empty).

6.1.3.4. Synchronous Temporal Behavior The CAN bus exhibits synchronous temporal behavior and the modeling of this synchronous behavior is inevitable if the arbitration mechanisms are to be included in the specification. SDL is an asynchronous language so the synchronous behavior of the bus is modeled explicitly by using a timer in the physical bus process which sends periodic pulses. At the end of each pulse, the physical bus broadcasts (currently implemented using non-ITU-T SDL) the appropriate signal. During arbitration, this signal will contain as a parameter the bit which is obtained from performing an and operation on any colliding message identification bits. The controller processes use the presence of signals from the physical bus to synchronize with it.

6.1.3.5. Specification Structure (and Run-Time Instance Notion) The specification is structured into controller processes, a manager process and a ‘‘noisy bus’’ block. The ‘‘noisy bus’’ block contains a noise generator process, used to check the robustness of the specification, and the physical bus process. As stated above, the manager process creates the controller processes dynamically, in order to create them with parameters depending on constants specified at the top level.Thus the different controllers are run-time instances of the controller process with different instantiation parameters.

6.1.4.

Statecharts Subsystem

The controllers have been modeled using Statecharts,with the STATEMATE tool.We have defined one generic model for the controllers (by means of the so called Generic Charts). Then this model is instantiated four times, one per controller. The generic model is presented in Figures 10 and 11. Figure 10 shows the interfaces of the controller: CAN bus, motor and keyboard which has also been modeled with STATEMATE. Figure 11 shows the behavior of the controller. This behavior is composed of two Statecharts and-states. The first and-state carries on the state of the window (RESTING, GOING UP, GOING DOWN). The second and-state, that contains the state named KB SERVER is in charge of transmitting messages from one door controller to the others.These messages are produced by the keyboard, and sent through the CAN bus. As we know, only the driver door is able to control the windows at the other door. Although the controller model is the same for all the

32

VOROS ETAL.

Keyboard From_KB To_Motor

STM_Control

MX_Motor

From_Motor @Control_SC

To_Bus

From_Bus

OG_Bus

Figure 10. Model of a controller with interfaces.

doors, the keyboard of the driver door is the only one that has buttons for the other doors. Therefore, the other doors never send events for another door because no such event is produced by their keyboards.

6.1.5.

MATRIXX Subsystem

The part of the model that is described using MATRIXX models the motor of the lift.We are not interested in an accurate model of the motor itself but of the motor interface with the controller (modeled in STATEMATE). In particular, the MATRIXX model receives and produces the same information that would receive and produce the motor. The interface of the motor with the controller has already been presented.The controller sends three events to the motor: move up, move down or stop.The motor sends an event to the controller (the window is blocked) and a continuous signal with the position of the window. The motor of the window lift works as follows. It rotates at a certain speed depending on the voltage supplied. In this case study we suppose that the voltage supplied to the motor is constant and therefore the speed of the motor is also constant. Whenever the motor produces a movement of the window of 15 millimeters in any direction it produces an event, that is used to compute the current position of the window. It should be taken into account that the initial position of the window is not known. Therefore, the system waits until detects that the window is blocked while is moving down,which means that the current position of the window is 0. After this point the system starts to compute the position.


Down_Stop/Win_Stop

33

Resting Stop_Up/Win_Up Up_Stop/Win_Stop

Down_Stop/Win_Stop Going_Down

Going_Up Down_Up/Win_Down

Up_Down/Win_Down

KB_Server

Figure 11. Behavior of a controller (STATEMATE).

In Figure 12 we can see the global model of the MATRIXX subsystem. It is composed of the following blocks:

event2level: it is in charge of providing to the Motor component with a continuous signal that indicates the movement direction. As the inputs from the controller are events, this block remembers which was the last event received, and outputs a continuous signal (Dir) that can have three different values: .

1: Motor moves up the window

.

0: Motor stopped

.

1: Motor moves down the window

Motor: It produces an event in Motor tics whenever a 15 millimeter movement takes place.

Initialization: it is in charge to detect that the window is in position 0 so PositionUpdate can start to compute the position of the window.When this condition is met it sets signal Start to a value greater than 0.Then Motor tics events pass through the AND gate to PositionUpdate.

testBlocking: detects that the window is blocked.

PositionUpdate: it is in charge of computing the position of the window.

0.1

event2level 2

Dir

99

Continuous

Motor

Figure 12. The MATRIXX model of the motor.

3 1 CU 2 CD

Stop Motor tics

Continuous

Initialization 1 Start

98 ValidMT AND

Continuous

testBlocking InitialBlock 97 4

T

Trig(SAF)

PositionUpdate 96

Blocked 2

Position

1

34 VOROS ETAL.


6.1.6.

35

Evaluation of the Methodology

The goal of this case study is to illustrate the use of the proposed methodology. The first benefit of the use of the specific approach was the allowance of a system model during most of the development cycle. The model is refined progressively and at any moment can be executed or animated, in order to be evaluated. This model-based approach fits with the basis of the proposed spiral model. Moreover, the specific approach allows to take advantage of the company’s know-how, as it is possible to use most of the used notations and to reuse components. In this case study, the CAN bus model can be easily reused within this framework.

6.2. 6.2.1.

Case Study 2: MASCARA, a MAC Layer Protocol forWireless ATM Networks Overview

MASCARA [33], [34] is a MAC layer protocol for wireless ATM networks which aims at offering the quality of a standard ATM network connection over wireless links. The wireless ATM architecture consists of ATM switches, Access Points and MobileTerminals. ATM switch is a standard customer premises access node, containing also mobility specific software and minimum hardware modifications; Access Point is the network element connected to the ATM switches with standard ATM connections; finally, Mobile Terminal is the end-user equipment that contains the wireless ATM radio adapter card, interfacing the 20 Mbits/sec air-interface. An overview of the wireless ATM environment in which MASCARA protocol participates, is depicted in Figure 13.

6.2.2.

Case Study Design

The following sections present how the proposed methodology has been used for the development of the MASCARA protocol.

6.2.2.1. Requirements Capture and Specification At this stage, the global model of the system described in Section 6.2.1 is refined. MASCARA is a MAC layer protocol that runs either at MobileTerminal side or at Access Point side. Due to limited space, in the sequel we illustrate part of the MASCARA protocol that is implemented as part of the protocol stack running on Access Points. As illustrated in Figure 14, MASCARA consists of the following sublayers:

Wireless Data Link Sublayer. It is split into the transmit and the receive part, and is responsible for recovering from the low quality of the air-interface.The DLC-ed cells illustrated in Figure 14, are ATM cell trains that have been enriched with control information related to MASCARA MAC layer.

36

VOROS ETAL.

Mobile Terminal Access Point

ATM Terminal

Control Station

Mobile Terminal

UNI

ATM Network

ATM Switch

Mobile Terminal

Access Point

Figure 13. An overview of a wireless ATM environment.

MAC Protocol Data Unit Handler. It manages the slot map according to the connection profile (AAL) and the Quality of Service (QoS) parameters.

MASCARA Scheduler. It is part of the MASCARA protocol variation running on the Access Point side, and is responsible for the efficient scheduling of the cell trains over the air. The Access Point that is responsible for a specific area, schedules cell trains among the Mobile Terminals that are moving within its territory.

6.2.2.2. System Architecture Design must be decided:

As explained in Section 3.2.2, during this stage it

1.

Identification of the Subsystems that Constitute the Overall System. Following the architecture depicted in Figure 14, MASCARA MAC layer is composed of the following subsystems: (1) the Wireless Data Link subsystem, (2) the MAC protocol Data Unit subsystem and (3) the Scheduler subsystem.

2.

Selection of the Notation that will be Used for Each Subsystem. Among the formalisms supported by the advanced toolset, SDL is the most suitable for describing MASCARA subsystems. Nevertheless, in order to take advantage of in-house component libraries described in Statecharts we have decided to use


37

ATM Layer

MASCARA Layer ATM Cells

WDLC Sub-Layer

Scheduler

DLC-ed Cells

MPDU Handler MPDU

Physical RF Layer Figure 14. MASCARA MAC layer as part of an ATM protocol stack running on an Access Point.

already available subsystems. For example, the segmentation and reassembly (SAR) subsystem belonging in the Wireless Data Link subsystem is already available in Statecharts. 3.

Definition of the Information Exchange Between Subsystems. The simulatable models describing the MASCARA protocol will be purely described SDL. Consequently, information exchange between subsystems degenerates to information exchange between SDL blocks, which is achieved through SDL channels.

4. Validation of the Architectural Decisions Taken so Far. The design decisions taken are validated in order to verify that the requirements that have been presented in Section 6.2.2.1 are met. The validation is achieved through simulation of the SDL models describing the system under development. At this point, only

38

VOROS ETAL.

functional requirements can be checked. The goal is to analyze if the decisions taken in points 1 to 3 are reasonable. Since SDL allows simulation of incomplete SDL descriptions, the validation of the design decisions can take place early enough in the development cycle. It can also be repeated over and over again as the SDL models become more accurate. At the end, the fully functional SDL model of the system is simulated.

6.2.2.3. System Co-Modeling and Detailed Design System design starts with models described both in SDL and Statecharts. As explained in Section 5.1, this is the structured model of the system. As soon as it is available, Statecharts models are translated in SDL. The outcome is a simulateble model purely described in SDL, and it is the flattened model of the system. Sections 6.2.3 and 6.2.4 outline the MASCARA protocol parts described in SDL and Statecharts respectively.

6.2.2.4. Hardware/Software Partitioning Hardware/software partitioning is achieved using MUSIC. The fully functional SDL description of MASCARA is automatically translated into SOLAR.The partitioning process consists of two main steps: 1.

Functionaldecomposition which aims at splitting a largebehavioral model for executionon several abstract processors.This step may create additional communication.

2. Structural reorganization that fixes the number of abstract processors and assigns a function to each of them. Each abstract processor may be implemented either in hardware or in software.

6.2.2.5. Targeting and Implementation Before committing to a specific hardware/ software allocation that meets the requirements described in Section 6.2.2.1, several alternatives have been examined. Hardware components are automatically translated in VHDL, while software components are translated in C.The interfaces required for hardware/software co-simulation are automatically generated by MUSIC.C/VHDL co-simulation allows the evaluation of a specific partitioning.TheVHDL code for hardware, the C code for software and the code implementing the interface between the two constitute the virtual prototype of the system.

6.2.3.

SDL Subsystem

6.2.3.1. General Concepts The SDL description of the MASCARA protocol consists of three main blocks.WDLC block implements theWireless Data Link sublayer described in Section 6.2.2.1; SCH block refers to the part of the SDL system that implements the MASCARA scheduler, and WDLC implements the MAC Protocol Data Unit Handler.


39

System MASCARA PR Declaration [(MPDU2Env)]

C7 MPDU

C5

[(SCH2MPDU)] SCH

C4

[(WDLC2SCH)] [(Env2MPDU)]

TB

C3

C2

[(Env2TB)] C6

[(MPDUJ2WDLC)]

C1

WDLC [(TB2WDLC)] C8 [(WDLC2Env)]

Figure 15. SDL framework for the MASCARA protocol.

TheTB block is not part of the MASCARA protocol. It is used during simulation for generating random MPDU sequences. Figure 15 illustrates the main subsystems of MASCARA described in SDL. As already explained in point 3 of Section 6.2.2.2, the information exchange between subsystems takes place through bi-directional SDL channels; for example, channel C4 connects the MPDU subsystem to SCH subsystem. At the end of each channel, signals lists depict the signals that each block accepts; for example, (SCH2MPDU) is the list of signals produced by SCH subsystem and consumed by MPDU subsystem.

6.2.3.2. Interfaces to the SDL Environment The communication with the external environment is achieved through SDL channels as well. As illustrated in Figure 14, the external environment for MASCARA is the ATM layer and the Physical RF layer. In Figure 15, the connection to the ATM layer is realized through channel C8, while the interface to the Physical layer is channel C7.

6.2.4.

Statecharts Subsystem

The subsystem of the MASCARA protocol that has been described in Statecharts is part of theWDLC block and implements the SAR unit (Segmentation And Reassembly) of the protocol. It is presented in Figure 16.

40

VOROS ETAL.

Segmentation Activity Other Event CONN_ACTIVATE /SegmentMPDU

ALLOC_CNF [Not Last Cell] /SendCell

SEG_IDLE

ALLOC_CNF [Last Cell] /SendCell

WAIT_ATM_MEMORY

OTHEREVENT CELL_RCVD /ReadFirstCell

CELL_RCVD [Not Last Cell] /ReadCell

RES_IDLE CELL_RCVD [Last Cell] /ReadCell /NewMPDU

WAIT_CELL

Reassembly Activity Figure 16. SAR unit described in statecharts.

In order to make the SAR unit part of the MASCARA SDL model, we have transformed it to SDL using advanced toolset’s feature for SDL to Statecharts conversion.The corresponding SDL model of Figure 16 is illustrated in Figure 17.

6.2.5.

SOLAR System

The upper part of Figure 18 illustrates the SOLAR model for the MASCARA protocol. The SDL blocks of Figure 15 have been transformed into SOLAR blocks in MUSIC.The behavior of each block is represented through a state table. The lower part of Figure 18 depicts the state table describing the internal states of the MPDU block.

6.2.6. Virtual Prototype The virtual prototype of MASCARA protocol consists of C code for software and VHDL for hardware. As illustrated in Figure 19,WDLC and SCH blocks have been described in C


41

Process Class_1 Wait_ATM_Memory

PR Declaration

SEG_IDLE

Other_Event

ALLOC_CNF

(Last)

SEG_IDLE

Send Cell ( )

SEG_IDLE

Other_Event

CONN_ACTIVATE

SEG_IDLE

Segment MPDU ( ) NEXTSTATE Wait_ATM_Memory

Wait_ATM_Memory

DECISION Cell

(NotLast)

Wait_ATM_Memory

Figure 17. SAR unit described in SDL.

and correspond to the software part of the system, while part of the SCH block has been described inVHDL and represents the hardware of the system. The distributed C/VHDL co-simulation of Figure 19 is composed of aVHDL simulator for hardware modules and C-debuggers for software modules. Each C debugger is interconnected to the VHDL simulator through a software bus which relies on the UNIX IPC layer.

6.2.7.

Evaluation of the Methodology

In order to evaluate the proposed methodology, the case study described in the current section has been compared to system designs of similar complexity borrowed from the telecommunication area. All the experiments used for evaluation purpose refer to the development of a part of the MAC layer protocol for wireless networks. More specifically, MASCARA protocol is a MAC layer protocol offering ATM services over wireless connections; a variation of Hiperlan/2 has been developed as part of an interconnection unit that connects wirelessly real time industrial networks [23], [38]; finally, part of the DECT protocol has been developed as well [24], [37]. Table 1 summarizes the set of tools used throughout the development of the three applications. For Hiperlan/2 specification UML has been employed for system specification, while for MASCARA and DECT the designers have used SDL. The difference between the two formalisms is that UML, as opposed to SDL, is not a formal notation. Moreover, Hiperlan/2 system does not employ hardware components in its final implementation. Consequently, the executable models describing the application are in C++. On the other

42

VOROS ETAL.

Figure 18. The SOLAR model of MASCARA protocol.

hand, MASCARA and DECT implementations involve both hardware and software components.The difference between the two is that hardware/software partitioning in the case of MASCARA is achieved through MUSIC, while in the case of DECT it has been done manually. Table 2 outlines the person-months spent at the main design stages during application development. Although the time spent for specification capturing is not significantly different between the three applications, there are differences as far as the production of an

C Debugger


43

SCH Communication Protocol I/O Primitives

MPDU_Rendez_vous

UNIX IPC Bus SCH_Rendez_vous

C Debugger

VHDL Simulator SCH

WDLC Communication Protocol

MPDU WDLC

I/O Primitives

C Debugger

C8_FIFO

C5_FIFO

WDLC_FIFO WDLC_FIFO Communication Protocol

TB TB_FIFO

I/O Primitives

Figure 19. Virtual prototype of the MASCARA protocol.

executable (simulatable) specification is concerned. MASCARA used SDL and Statecharts, while DECTused SDL for specifying the system under development. The formal semantics of the formalisms employed allowed simulations of system models early enough in the development cycle. As a result, the executable specifications of the system under development were available much earlier compared to the one of Hiperlan/2. The person-months consumed for the latter, were significantly increased due to the fact that in order to produce executable models from UML, it is required a detailed specification so as to allow the UML tools to produce the C++ code; every time the designer needs to simulate the system has to produce C++ code. This is in contrast to the cases of MASCARA and DECT, where system simulation was achieved using the specification formalisms used during system specification capturing. Concerning the person-months required for producing the executable specification, there is an improvement in the case of MASCARA application compared to the DECT case study. This is mainly due to the fact that part of the protocol was already available in the form of components described in Statecharts. The ability offered by the advanced toolset to incorporate seamlessly Statechart models in SDL specifications enabled faster production of system’s executable specification. Additionally, the re-use of components

44

VOROS ETAL.

Table 1. Tools and Formalisms Used

MAC Layer HIPERLAN/2 MASCARA DECT

Specification Capture

Executable Specification

HW-SW Partitioning

Virtual Prototype

UML SDL and Statecharts SDL

C++ SDL SDL

MUSIC Manual

C++ C,VHDL C,VHDL

Table 2. Person-Months Consumed at Various Design Stages

MAC Layer HIPERLAN/2 MASCARA DECT

Specification Capture

Executable Specification

Virtual Prototype

Total

7 6.5 5

11 4.5 5

6 2 8

24 13 18

that have already been successfully used in the past, contributed to the quality improvement of the final system. As far as hardware/software partitioning is concerned, in the case of DECTapplication it was done manually. The designers, based on their experience, had decided from early design stages which subsystems should be implemented in hardware. The result was the separate development of hardware and software modules; the latter, caused significant inconsistencies in hardware/software communication and resulted in delays during integration.On the other hand,the use of MUSIC for hardware/software partitioning in the case of MASCARA protocol improved significantly the time spent in hardware/ software allocation.The final partitioning scheme was decided based on a fully functional SDL specification of the overall system. The ability to evaluate different hardware/ software allocations before committing to the final one, allowed efficient system partitioning. An additional factor that reduced the time spent at this stage was the fact that C, VHDL and the interfaces required for hardware/software co-simulation were automatically generated by MUSIC.The latter, led to virtual prototypes of the MASCARA protocol consuming less person months compared to the DECT application. As far as Hiperlan/2 is concerned, the virtual prototype of the protocol did not involve hardware and relied on the C++ code produced directly from the UML specification.

7. Conclusions In the previous sections we presented an overview of the COMITYmethodology.The key aspect of the proposed approach is the use of multiple formalisms for system specification, allowing effective modeling in the case where more than one specification languages are used throughout system development. Moreover, an advanced set of tools is available through which the designer is able to describe the system under design using combinations of SDL, Statecharts and MATRIXX. For systems that their final implementation consists of hardware and software modules, interactive hardware/software partitioning allows


45

A

A

B

B

Figure 20. Transformation of simple SDL transitions to StateChart transitions.

evaluation of the various implementation alternatives, and automatic generation of the C/ VHDL code for the virtual prototype of the system.The effectiveness of the methodology exhibited in practice through two representative case studies: a window lift mechanism described using SDL, Statecharts and MATRIX X, and a MAC layer protocol where SDL and Statecharts were employed.

Appendix This section presents the basic primitives of the SDL-Statechart co-modeling module. Each Statechart is transformed to an SDL process (and vice versa) according to the following rules:

SDL start symbols are converted into initial StateChart states;

SDL stop symbols are converted into final StateChart states;

Other SDL states are converted into usual StateChart states, without refining into nested diagrams.

SDL transitions are transformed into StateChart transitions according to a direct scheme as illustrated in the next paragraphs. In Figure 20,the SDL transition is considered as a single StateChart transition. In SDL, both decision branches are merely temporary branches and the final state is the same whatever the case. In Figure 21, ‘‘Join’’ and ‘‘Label’’ statements are converted into one transition for each possible path from the Join statement to each terminal statement that can be reached

46

VOROS ETAL.

A

B

A

B

D

C

D

X

C

Figure 21. Transformation of SDL Join and Label transitions to StateChart transitions.

e1

e1

Event 1

x

Event 1

Event 2 Event 2 First State

First State

e2

e2

Figure 22. Transformation of StateChart conditional transition into SDL.

through the label statement. Note that the temporary states associated with each label (such as X) are eliminated. Several temporary states, possible nested, may exist in an SDL process. In this case,the translation scheme presented can generate many StateChart transitions, and a complementary method is needed to eliminate all transitions whose input and output states are both temporary. The SDL to StateChart transformation presented so far, can be reversed, i.e., a StateChart model can also be translated to an SDL model. A number of restrictions still apply, and in particular the StateChart model taken in as input must contain one state diagram only. The generated SDL model is therefore a process (more precisely a Finite State Machine) that will be encapsulated into a block, itself being included in a system where signals, signal lists, channels or routes can be declared. Figures 22 and 23 illustrate the translation process. At first glance, StateChart and SDL notations seem rather complementary than in competition. StateChart provides facilities to describe system’s dynamic at several layers, whereas SDL provides a complete graphical language to describe system’s dynamic at the most detailed level. From the engineering point of view, the two notations appear complementary. StateChart is used in the preliminary steps of the system development, while SDL will be used during detailed design in order to describe the complete behavior of the system.


47

e1 e1 Event 1 Event 1 C [expr = val1]

e2

[expr = val2]

e3

expr

(val1)

(val2)

e2

e2

Figure 23. Transformation of StateChart conditional transition into SDL.

Acknowledgements This work has been performed in the frameworkof the ESPRITproject 23015 COMITY. The COMITYproject is partly funded by the European Commission.The authors would like to acknowledge the contributions of their colleagues fromVerilog France, Aerospatiale France, BMW Germany, Intracom Greece, C-LAB Germany, DIT/UPM Spain, TIMA France and ISI France. The work undertaken by the University of Patras has been made possible through a grand of Intracom to University of Patras.

Notes 1. Real time constraints imposed by system’s non functional requirements are handled only at the tool level and not as part of the methodology presented. For example, in the case of SDL models the designer can use SDL timers to define deadlines whenever it is required. 2. In the general case, a system may contain more than one subsystem specified in the same formalism. A cosimulation, therefore, may include more than one instance of the same simulator and we therefore refer to simulator instances in the sequel.

References 1. Ismail, T., K. O’Brien, and A. Jerraya. Partif: Interactive System-Level Partitioning.VLSI Design, vol. 3, pp. 333^345,1995. 2. Vahid, F., and D. Gajski. Closeness Metrics for System Level Functional Partitioning. In Proceedings EURO DAC, EURO-VHDL, September 1995. 3. Vahid, F., and D. Gajski. Specification Partitioning for System Design. In Proceedings DAC, June 1992.

48

VOROS ETAL.

4. Jerraya, A., and K. O’Brien. SOLAR: An Intermediate Format for System-Level Modeling and Synthesis. J. Rozenblit, K. Buchenrieder (Eds), IEEE Press, Piscataway, NJ,1994. 5. Ernst, R., J. Henkel, and T. Benner. Hardware^Software Cosynthesis for Microcontrollers. IEEE Design & Test of Computers, vol.10, no. 4, pp. 64^75,1993. 6. Gajski, D. D., F. Vahid, S. Narayan, and J. Gong. Specification and Design of Embedded Systems. Prentice Hall,1994. 7. Sa¤nchez Ferna¤ndez, L. et al. Hardware^Software Prototyping from LOTOS. Design Automation for Embedded Systems, vol. 3, nos. 2/3, pp.117^148,1998. 8. The Ptolemy Project. http://ptolemy.eecs.berkeley.edu. 9. ESPRIT 23015COMITYCodesign Method and IntegratedTools forAdvanced Embedded Bystem. http:// www.cordis.lu/esprit/src/23015.htm. 10. ESPRIT 23015COMITYCodesign Method and Integrated Tools for Advanced Embedded System. http:// www.it.uc3m.es/comity/. 11. Balboni, A., W. Fornaciari, and D. Sciuto. Co-Synthesis and Co-Simulation of Control-Dominated Embedded Systems. Design Automation for Embedded Systems, vol.1, no. 3, pp. 257^289,1996. 12. SystemC. SystemC Community. http://www.systemc.org. 13. Vercauteren, S., J.V. D. Steen, and D.Verkest. Combining Software Synthesis and Hardware/Software Interface Generation to Meet Hard Real-Time Constraints. In DATE’99,1999. 14. Design & Reuse. http://www.design-reuse.com. 15. RAPID. Reusable Application-Specific Intellectual Property Developers. http://www.rapid.org. 16. VSI Alliance.Virtual Socket Interface. http://www.vsi.org. 17. Tsasakou, S., N.Voros, N. Birbas, M. Koziotis, and G. Papadopoulos. High-Level Co-Simulation Based on the Extension of Processor Simulators. Journal of Systems Architecture, vol. 47, no.1, pp.1^13, January 2001. 18. Van Rompaey, K., D.Verkest, I. Bolsens, and I. De Man. CoWare-Co-Design of DSP Systems. In NATOASI Hardware/Software Co-Design,Tremezzo, Italy,1995. 19. Klein, R. A Hardware-Software Co-Simulation Environment. In Proceedings of RSP’ 96. IEEE CS Press, pp. 173^177,1996. 20. Boehm, B. A Spiral Model of Software Development and Enhancement. Science of Computer Programming, vol. 8, pp. 231^274,1988. 21. Voros, N., S. Batistatos, and N. Pronios. Evaluation Report of the SoA Toolset for the Telecom Experiment. Technical Report. COMITY Project, 1998 ESPRIT/23015/WP3/D32.2. 22. Fuchs M. and N. Schreiber. Evaluation Report of the State of the Art Toolset for the Automotive Experiment. Technical Report. COMITY Project, ESPRIT/23015/WP3/D31.2,1998. 23. Voros, N., M. Larborn, P. Jansson, and L. Tossa. Specification of the Application Experiments. AITWOODDES Project, IST 10069/WP4.1/D12, 2000. 24. Tsasakou, S., C. Dre, and H. Karathanasis. High-Level Description of the DECT/MAC Layer. CODAC Project, ESPRIT Project 24129/D4,1997. 25. Adida, C., P. Buttel, R. Ledain, and X. Granger. Evaluation Report of the State of the Art Toolset for the Avionics Experiment.Technical Report. COMITY Project, ESPRIT/23015/WP3/D30.2,1998. 26. Alonso, A., N. Martinez, S. Pickin, and L. Sa¤nchez, and S. Arab. COMITY Method Guide. Consolidated Advanced Toolset Version.Technical Report. COMITY Project, ESPRIT/23015/WP2/D21.2.2,1998. 27. Roux, J., S. Loembe, S. Arab, E. Kleinjohann, L. Erpenbach, L. Sanchez, and A. Alonso. COMITY User DocumentationAdvanced Toolset (v2). Technical Report. COMITY Project, ESPRIT/23015/WP2/SEP98/ D21.3.2,1998. 28. Harel, D. StateCharts: AVisual Formalism for Complex Systems. IEEE Computer, vol. 21,1987. 29. ITU-T: CCITT Specification and Description Language (SDL). ITU-T Recommendation Z.100 (03/93), 1993. 30. ISI: MATRIXX Product Family Reference. ISI,1996. 31. Verilog: ObjectGEODE: SDL Editor-User’s Guide.Verilog,1997. 32. Jerraya, A., M. Romdhani,C.Valderrama,G. Marchioro, A.Changuel, and J. Daveau.COSMOS: ATransformational Co-Design Tool for Multiprocessors Architecture. In Hardware/Software Co-Design: Principles and Practice. Kluwer Academic Publishers,1997.


49

33. Bauchot, F., S. Decrauzat,G. Marmigere, L. Merakos, and N. Passas. MASCARA, a MAC Protocol forWireless ATM. In ACTS Mobile Summit, 1996. 34. Mikkonen, J., and J. Kruys.The Magic WAND: AWireless ATM Access System. In ACTS Mobile Summit, 1996. 35. Roux, J. L., S. Stroop, S. Loembe, S. Arab, L. Sanchez, C. Hote, S. Pickin, A. Jerraya, and B. Kleinjohann. Specification of the Advanced Toolset. Technical Report. COMITY Project, ESPRIT/23015/WP2/D21.1, 1998. 36. Mariatos, E. Hardware/Software Co-Design Using Object Oriented Methods and Tools. Ph.D. thesis. University of Patras, Dept. of Electrical Engineering, Greece,1998. 37. DECT:The Standard Explained. February 1997. 38. ETSI: Broadband Radio Access Networks (BRAN); HIPERLAN Type 2: System Overview.TR 101683 v1.1.1, February 2000. 39. Sa¤nchez Ferna¤ndez, L., S. Pickin, A. Groba, N. Mart|¤ nez, and A. Alonso. UF: Architectural Language for Multiformalism Descriptions. In Forum on Design Languages, FDL’99,1999.

voros 5..49 - CiteSeerX

voros 5..49 - CiteSeerX

Suggest Documents