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

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

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

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

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

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

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

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

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

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

The Advanced Toolset The synopsis of the advanced toolset

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

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

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

Car Windows Lift

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

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

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

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

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

MATRIXx Subsystem

MASCARA (a MAC Layer Protocol for Wireless ATM Networks)

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

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

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

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

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

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

Statecharts Subsystem (SAR)

Virtual Prototype Interconnected Co-simulation

Evaluation of the Methodology