1 / 38

Hardware/Software Codesign Representation Models

Hardware/Software Codesign Representation Models. Ly Le and Kyung Kim Department of Electrical Engineering University of Washington 11/9/2004. Outline Overview. Definition Purposes Representation models Codesign tools Summary. Definition. Codesign Representation Model

stevev
Download Presentation

Hardware/Software Codesign Representation Models

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. Hardware/Software Codesign Representation Models Ly Le and Kyung Kim Department of Electrical Engineering University of Washington 11/9/2004

  2. Outline Overview • Definition • Purposes • Representation models • Codesign tools • Summary

  3. Definition Codesign Representation Model • A representation that can be used to capture the features of the system and describe its functionalities • Ideally capable of handling concurrent and sequential behavior • Allows HW/SW partitioning to be delayed until trade-offs can be made • Typically used at a high-level in the design process

  4. Purposes • Increase system complexity • Ensure system reliability • Lower cost • Reduce time-to-market

  5. Well-known Models that codesign representations are derived from: • Finite State Machines • Discrete-Event Systems • Petri Nets • Dataflow Graphs • Communicating Processes • Synchronous/Reactive Models

  6. Finite State Machines • The classical FSM is composed of states, inputs, and outputs • The classical FSM does not have concurrency and hierarchy • Extensions and variations of FSM are developed

  7. 3 Models of Finite State Machines • SOLAR • Codesign Finite State Machine (CFSM) • Statecharts

  8. SOLAR • High-level concepts for control-flow dominated system • Includes hierarchy and concurrency • Uses synchronously combined (with communication) multiple FSMs • Intermediate format for high-level to system-level

  9. Codesign Finite State Machine • Used for relatively low complexity control-oriented systems • Uses multiple FSM running asynchronously • ‘event’ is broadcasted between FSMs for communication • Intermediate representation between high-level and system-level

  10. Statecharts • Used for complex reactive systems with concurrency and hierarchy • Uses instantaneous broadcast where the receiver reacts immediately upon broadcast

  11. Discrete-Event Systems • They are systems that evolve at discrete time when events occur (otherwise remain constant) • All events have values and time stamps • Require great computational cost • Used for communication networks and automated manufacturing processes

  12. Petri Nets • Consist of places, tokens, transitions, and arcs • Well known for concurrency and asynchronous nature • Lack hierarchical decomposition and expressiveness for computations

  13. 2 Models of Petri Nets • Hierarchical Petri Nets (HPN) • PURE

  14. Hierarchical Petri Nets • Inherit concurrency and asynchrony • Incorporate hierarchy for more complex systems

  15. PURE • Consist of control and computational/data part • Timed Petri Nets with restricted transition rules are used • Pairs of I/O operations used for communication between modules • Show consistent HW/SW representation

  16. Dataflow Graphs 5 X 4 Y • Include nodes for computations and arcs for the order of computations • Often used in modeling data-dominated systems Example: + + Control Step 1 + Control Step 2 + Control Step 3

  17. Dataflow Models Three models: • Dataflow Process Networks • Model Graph • Conditional Process Graph

  18. Dataflow Process Network • composed of multiple of concurrent processes • Specify applications written in C or Mathlab • Mapped into microprocessor architecture • Compaan tool used for Mathlab applications • Used in real-time, high-performance signal processing applications • Video consumer appliances • Adaptive radar processing • Mobile communication devices

  19. Dataflow Process Networks

  20. Dataflow Process Networks (Cont.) Two approaches: • Synchronous data flow (SDF) • Nodes consuming and producing a fixed number of data in each fire • Cyclo-static data flow (CSDF) • Nodes cyclically having variable amounts of data

  21. Model Graph • Concurrent processes communicating via FIFO-ordered queue • Used in real-time operating systems because of: • processes enabled only when the required input data is present • time-constraints of each process

  22. Conditional Process Graph • Consist of multiple communicating processes sharing the same resources • Need a scheduler to control the dataflow • Used in both data and control oriented systems • Time-constraints on each process • Condition to activate the process execution

  23. Communicating Sequential Processes Model (CSP) • Include a set of concurrent processes • Use a synchronizing protocol for communication • Be suitable to system-level simulation and synthesis • VHDL or Verilog used for hardware description

  24. Synchronous/Reactive Models • Represent for reactive, real-time systems • Produce outputs simultaneously with input stimuli • No observable time delay in the reaction

  25. Synchronous/Reactive Models (Cont.) Three models: • State based formalisms • control oriented systems • Multiple clocked recurrent systems (MCRSs) • data oriented systems • LUSTRE language • Synchronous Processes • both control and data oriented systems • Processes activated by events with a tag • ESTEREL language

  26. ATM Network Interface Card Application

  27. ATM Network Interface Card Application (Cont.) • Composed of concurrent processes (TCP, IP, AAL, ATM) • Processes asynchronously communicating via signal routes and channels • Used dataflow process networks as a representation model

  28. Specification and Description Language (SDL) • Used for specifying and validating the NIC system • Good for communicating systems • Generating a high level block diagram of NIC system

  29. Specification and Description Language (SDL) (Cont.) Advantages • Be able to investigate trade-offs before HW/SW partitioning • Avoid a late detection of errors • Lower cost • Faster design time Disadvantage • Lack of some arithmetic operation • Not suitable for DSP applications

  30. Esterel • A design environment to develop both HW/SW at the same time • Used for reactive real-time system • A synchronous language that compiles to the finite state machine

  31. Esterel (cont.) • Module based • Uses signals as inputs and outputs • Signals have status (present or absent) and values • Uses input relations to set conditions relation Up # Down; %incompatibility • Uses parallel statements

  32. Esterel (cont.) • Functions, procedures, and tasks function compareTime (Time, Time) : boolean; procedure TranslateAndRotate (Rectangle) (Coord, integer); task MoveRobot (Coord) (Rectangle); • Variable var x:=0 : integer in var x:integer • Assignment x := 0; x := x+1;

  33. Example coding for Esterel module ABCRO: input A, B, C, R; output O; loop [await A || await B || await C ]; emit O each R end module

  34. Example coding (cont.) >; Output: >A; Output: >B; Output: >C; Output: O >R; Output: >A B C; Output: O

  35. Summary • Using representation models is very important • Reduction in development cost • Reduction in design time • Performance enhancement

  36. References • Luis Alejandro Cortes, Petru Eles and Zebo Peng, “A Survey on Hardware/Software Codesign Representation Models” Linkoping University • Jean-Marc Daveau, Gilberto Marchioro, Ahmed Amine Jerraya, “Hardware/Software Co-design of an ATM Network Interface Card: A Case Study” • http://www-cad.eecs.berkeley.edu/Respep/Research/hsc/abstract.html • A. Benveniste and G. Berry, “The Synchronous Approach to Reactive and Real-Time Systems,” in Proc. IEEE, vol. 79, pp. 1270-1282, Sept. 1991. • T. Ben Ismail and A. Jerraya, “Synthesis Steps and Design Models for Codesign,” in IEEE Computer, vol. 28, pp. 44-52, Feb. 1995. • G. Berry and G. Gonthier, “The ESTEREL synchronous programming language: design, semantics, implementation,” in Science of Computer Programming, vol. 19, pp. 83-152, Nov. 1992. • F. Boussinot and R. de Simone, “The ESTEREL Language,” in Proc. IEEE, vol. 79, pp. 1293-1304, Sept. 1991. • C. G. Cassandras, Discrete Event Systems: Modeling and Performance Analysis. Boston, MA: Aksen Associates,1993. • M. Chiodo, P. Giusto, H. Hsieh, A. Jurecska, L. Lavagno, and A. Sangiovanni-Vicentelli, “A Formal Specification Model for Hardware/Software Codesign,” Technical Report UCB/ERL M93/48, Dept. EECS, University of California, Berkeley, June 1993. • [Chi94] M. Chiodo, P. Giusto, A. Jurecska, H. Hsieh, A. Sangiovanni-Vicentelli, and L. Lavagno, “Hardware-Software • Gerard Berry, Centre de Mathematiques Appliquees, and Ecole des Mines and INRIA, “The Esterel v5 Language Primer Version 5.21 release 2.0”

More Related