Hardware/Software Codesign Representation Models

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

22. 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

23. 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

24. 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

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

26. 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

27. ATM Network Interface Card Application

28. 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

29. 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

31. 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

32. 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

33. 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

34. 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;

35. 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

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

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

38. 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”