1 / 24

System Synthesis for Multiprocessor Embedded Applications

System Synthesis for Multiprocessor Embedded Applications. UFRGS Informática. Flávio R. Wagner Marcio Oyamada Luigi Carro Marcio Kreutz Universidade Federal do Rio Grande do Sul Porto Alegre, Brazil DATE´2000, Paris, Frande, March 2000. UFRGS. Outline. 1. Introduction

aglaia
Download Presentation

System Synthesis for Multiprocessor Embedded Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. System Synthesis for Multiprocessor Embedded Applications UFRGS Informática Flávio R. Wagner Marcio Oyamada Luigi Carro Marcio Kreutz Universidade Federal do Rio Grande do Sul Porto Alegre, Brazil DATE´2000, Paris, Frande, March 2000 UFRGS

  2. Outline 1. Introduction 2. Modeling and simulation infra-structure 3. Hardware-software co-design methodology 4. Co-simulation 5. Example 6. Synthesis 7. Final remarks

  3. 1. Introduction • embedded electronic systems: control of physical processes and equipments • target architecture • off-the-shelf or dedicated processors (DSP, RISC, microcontrollers) • software • dedicated analog and digital hardware • requirements for a design environment • appropriate specification mechanisms for various abstraction levels • stepwise refinement process • co-simulation

  4. Motivation • existing approaches for design environments • single language / computation model for high-level specifications • multi-language environments • object-oriented design • our solution combines benefits from all these approaches • object-oriented specification and simulation • single environment for the whole design process • various types of models are possible • single, high-level abstract specification • computation model: procedural, state machines • co-specification and co-simulation: discrete, analog, VHDL

  5. 2. Modeling and simulation infra-structure SIMOO environment • object-oriented modeling and simulation of discrete systems • multiparadigm modeling • each object in the model may follow a different paradigm • paradigm is a combination of aspects for the behavior description • visual interactive simulation • graphical description of the static structure • behavior described in C++ or state diagrams annotated with C++ • simulation library implements the multiple paradigms

  6. SIMOO: software architecture Model Editor Tool C++ code executable code compiler library of autonomous objects SIMOO class library • default user interface automatically added to all models • querying models, tracking and steering experiments • • interface objects • • visualization of results, data collection, interactive data input

  7. 3. Hw-sw codesign methodology • initial abstract specification • C++ or state diagrams annotated with C++ • objects corresponding to the physical world may be modeled by a continuous behavior • design proceeds through a stepwise refinement • hierarchical refinement: same abstraction level • abstraction refinement: design decisions are taken • abstract objects are mapped into objects of a target architecture • digital or analog hardware, software • validation of all possible models by co-simulation

  8. Library-based synthesis • selection of hardware objects from a previously built library of classes for the possible target architectures • digital hardware objects previously described in VHDL • no automatic synthesis from C++ to VHDL • software objects may be automatically generated from the abstract specification • from C to assembly languages of the selected processors

  9. 4. Co-simulation • co-simulation for the validation of the initial specification • discrete behavior - algorithms or state diagrams • continuous behavior - physical environment • co-simulation for the validation of possible implementations • discrete behavior - algorithms or state diagrams • for parts that have not been yet refined • for software parts • continuous behavior • for the physical environment • for analog hardware • VHDL • for digital hardware

  10. Coupling SIMOO and VHDL SIMOO simulator VHDL simulator

  11. Coupling SIMOO and VHDL • interfaces in both domains are automatically generated • C-file in the VHDL domain • interface object in the SIMOO domain • interfaces are responsible for ... • communication - exchange of data and format conversion • synchronization between simulators • conservative approach • communication between simulators by sockets • distributed simulation is possible • SIMOO currently runs on Windows • VSS runs on Unix workstations

  12. Hybrid discrete-continuous simulation • objects with analog behavior • modeled by a set of differential equations • implement the numerical integration method • object attribute defines integration time step • signal-flow approach • mathematical functions from inputs to outputs • appropriate for objects that ... • don´t have a physical implementation yet • model the physical environment • are modeled at a higher abstraction level than basic components (PID controllers, converters, filters)

  13. Hybrid discrete-continuous simulation • current situation • differential equations directly described in C++ • integration time step must be defined by the programmer • scheduling the execution of analog objects • if there are more than one AO and they communicate with each other, they must be scheduled at each time step and exchange messages • if not, an AO may be scheduled at intervals that depend on the discrete objects and then execute several integration steps • future work • better modeling environment • better time advancement mechanism, including automatic time step definition • integration with Matlab / Simulink

  14. 5. Example • benchmark for specification of heterogeneous systems • physical plant: crane with a load, moving along a track • control • assures smooth movement, without bumps and oscillations • verifies if displacement does not exceed limits and if angle of the load is acceptable (emergency break) • auto-test of sensors

  15. First modeling of the crane physical plant controls car movement, sensor checking, output forces to Actuators drives the dc motor (speed), control breaks and emergency break checks plausibility of car position and load angle

  16. First modeling of the crane • physical plant Plant_rk is an object with continuous behavior • all other objects have discrete behavior • M_Control combines two computation models • control algorithm for movement is a discrete computation of the state-variable method q n+1=A*q n + B*[Motor_Voltage Car_Position]T at each 10 ms • sensor checking is an FSM • Diagnosis is an FSM • Actuators is an algorithm

  17. Second modeling of the crane M_Control split into two objects FSM for sensor checking main control algorithm, arithmetic operations

  18. Third modeling of the crane FSMs (Job_Control and Diagnosis) merged into a single object to be implemented as digital hardware and modeled in VHDL

  19. 6. Synthesis • library of previously characterized processors • characterization by attributes size of binary word types of instructions memory operand addressing modes execution time (in clock cycles) of each instruction number of busses to access memory type of memory number of registers use of pipeline and depth of eventual pipeline use of harvard architecture • current library: C25, 8051, RISCO

  20. Characterizing the application application is characterized as: - data-dominated - memory-dominated - control-dominated C++ CDFG machine- independent 3-address code M P APP = APM = P + M + C P + M + C C APC = P + M + C machine-independent code is fitted to each type of processor architecture: RISC, DSP, microcontroller

  21. Selecting the processor • performance profiles measure, for the given application, the relative cost of the processor for each aspect (data, control, memory) • selection algorithm • analyzes the application and performance profiles • chooses the processor best suited for the application • currently: measure of the mean geometric distance between the desired application profiles and the performance profiles Pi PPPi = Pi + Mi + Ci Mi PPMi = Pi + Mi + Ci Ci PPCi = Pi + Mi + Ci

  22. Selecting the processor examples from the crane modeling Control Processor APM APC APP PPM PPC PPP Distance 8051 0.304 0.298 0.396 0.329 0.213 0.456 0.107 RISCO 0.184 0.350 0.464 0.098 0.624 0.277 0.342 C25 0.001 0.430 0.568 0.084 0.700 0.214 0.452 Multiplication Processor APM APC APP PPM PPC PPP Distance 8051 0.543 0.157 0.299 0.091 0.070 0.838 0.708 RISCO 0.301 0.240 0.457 0.029 0.497 0.473 0.374 C25 0.006 0.342 0.651 0.019 0.664 0.315 0.465

  23. 7. Final remarks • SIMOO is used as a high-level modeling and verification front-end • co-simulation: SIMOO used as a seamless environment for validating both high-level designs and implementations • stepwise refinement: progressive replacement of abstract descriptions by implementation descriptions • synthesis • target architecture is a multiprocessor platform • semi-automatic selection of the processors that best match the desired design requirements for the given objects

  24. Future work • basic modeling and simulation infra-structure • optimize the hybrid modeling and simulation mechanisms • distributed simulation with an optimistic protocol • multi-language approach: integrate other languages • synthesis • communication synthesis • find optimal selection algorithms and consider other requirements (cost, area, power) • explore partitioning of objects into processors • model larger examples where multiprocessor platforms are needed

More Related