1. Hardware/Software Co-Design of Complex Embedded System NIKOLAOS S. VOROS, LUIS SANCHES, ALEJANDRO ALONSO, ALEXIOS N. BIRBAS, MICHAEL BIRBAS, AHMED JERRAYA Design Automation for Embedded Systems,8,5-49,2003 Yuan-Shiu Chen

2. Introduction Hardware/software co-design methodology focusing  Use of multiple specification formalisms during early design stages  Efficient hardware/software partitioning  An innovative methodology that take account the need of the formalisms

3. Current Trends in Electronic System Design Methodological support. can be conceived from various points of view. Multi-formalism specification. no perfect language is suitable for any kind of system. Hard real-time requirement Design reuse. reduce the development time

4. The Industrial Practice  Starts with an informal system specification  Formal system specification is carry out. employ multiple formalisms for describing different parts of the same application  Architecture exploration and system partitione. employ informal system specification of the system as input  Concurrent hardware/software development. interaction required between the hardware and software design teams is achieved through informal system specification

5. COMITY ( CO-design Methodology and Integrated Tools for embedded sYstem ) The key aspects on which COMITY methodology focuses  Use of multiple formalisms for system specification  Efficient system partitioning  Prototyping and testing supported by tools

6. COMITY : Methodological Phases Requirements Capture and Specification. obtain as much information as possible about the requirements of the system. independent of the notation. design flow that may be chosen

7. COMITY : Methodological Phases System Architecture Design. Identification of Main Components. Information Exchange Between Subsystems exchanged consists of data and control information. Model Validation validate that the logical model (system resource are not considered) fulfill system requirement

8. COMITY : Methodological Phases  Co-Modeling and Detailed Design. refinement of the previously identified components. co-modeling is based on translation of whole components form one notation to the other  Model Partitioning. decided which modules will be implemented as software or hardware.additional module is required that will enable the hardware signals to be realized by software

9. COMITY : Methodological Phases Targeting and Implementation. C code must be generated taking into account the operating system on which the software part will run. the VHDL code will be transferred to silicon

10. COMITY : Specification Formalisms Supported Several advantage by using multi-notation approach. Use of the Most Suitable Notation for a Given Part of the System. Design of Hybrid Systems Formalisms : StateCharts, SDL (Specification and Description Language), MATRIXx

11. The Advanced Toolset The synopsis of the advanced toolset

12. Co-Modeling Tools ( ObjectGEODE ) AS part of the advanced toolset, co-modeling using SDL and Statecharts is allowed A set of transformation rules between StateChart and SDL, have been realized in the ObjectGEODE.Describe parts of the system using either SDL or Statecharts. Transform the StateChart model into a SDL model.Complete the detailed design in SDL.Simulate the SDL model

13. Partitioning Tools (MUSIC) Uses an intermediate format, named SOLAR

14. Transformational Partitioning. The behavioral partition relies upon the operations of cutting and merging of extend finite state machines (FSM).Merge : combines the sequential machines into a single machine.Split : cuts a sequential machine to produce several machines in parallel.Cut : transforms a parallel machine into a set of machines either interconnected or communication

15. Car Windows Lift

16. System Architecture Design Identification of the Components that will Form the System four controller and motor on each door, one bus  Selection of the Notation that will be Used for each Component.Controller use StateCharts (suitable language to model control oriented system).bus use SDL (good language for communication related system).motor use MATRIXx

17. System Architecture Design cont. Definition of the Information Exchange Between Subsystems. controller send events to motor : move up, down and stop with the position of the window. motor send event to controller : window is blocked. controller send message to bus or to receive from it. Message compose the movement of the window and which controller message is sent

18. System Architecture Design cont. Validation of the Architecture Decisions Taken so Far. Analyze if the decisions taken in the previous phase are reasonable System Co-Modeling and detailed Design. Models to be developed in each notation (Statechart, SDL, MATRIXx) are produced

19. System Architecture Design cont. Hardware/Software Partitioning. In this case only the controller should be partitioned.partition has been already done in the architectural design phase.motor and bus only to model the environment in which controller work  Targeting and Implementation. Generate software and hardware code

20. Statecharts Subsystem Stop_Down/Win_Down Down_Up/Win_Up KB_SERVER is in charge of transmitting message from one door controller to the other

21. MATRIXx Subsystem

22. MASCARA (a MAC Layer Protocol for Wireless ATM Networks)

23. Requirement Capture and Specification Wireless Data Link Sublayer : Split into the transmit and receive part. Enrich with control information related to MASCARA MAC layer MASCARA Scheduler : schedules cell trains among the Mobile Terminals that are moving within its territory MAC Protocol Data Unit Handler MASCARA MAC Layer

24. System Architecture Design Identification of the Subsystems that Constitute the Overall System. Wireless Data Link subsystem, MAC protocol Data Unit subsystem, the Scheduler subsystem Selection of the Notation that will be Used for Each Subsystem. SDL is the most suitable for describing MASCARA subsystems. segmentation and reassembly(SAR) subsystem belonging in the Wireless Data Link subsystem is available in Statechart

25. System Architecture Design cont. Definition of the Information Exchange Between Subsystems.The simulatable models describing the MASCARA protocol will be purely described SDL, so information exchange only between SDL blocks Validation of the Architecture Decisions Taken so Far. The validation is achieved through simulation of the SDL models describing the system under the development

26. System Architecture Design cont. System Co-Modeling and Detailed design. Design start with models described both in SDL an Statecharts.The outcome is a simulatable model purely described in SDL (Statecharts models are translated in SDL) Hardware/Software Partitioning. Hardware/Software partitioning is achieved using MUSIC.The SDL is automatically translated into SOLAR

27. System Architecture Design cont. Targeting and Implementation.Hardware components are automatically translated in VHDL.Software component are translated in C

28. SDL Subsystem TB : not part of the MASCARA protocol. It is used during simulation for generating random MPDU sequences SDL framework for the MASCARA protocol

29. Statecharts Subsystem (SAR)

30. Virtual Prototype Interconnected Co-simulation

31. Evaluation of the Methodology