Download codesign-20041208163049

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
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
Purposes
Increase system complexity
Ensure system reliability
Lower cost
Reduce time-to-market
Well-known Models that codesign
representations are derived from:
Finite State Machines
Discrete-Event Systems
Petri Nets
Dataflow Graphs
Communicating Processes
Synchronous/Reactive Models
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
3 Models of Finite State Machines
SOLAR
Codesign Finite State Machine (CFSM)
Statecharts
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
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
Statecharts
Used for complex reactive systems with
concurrency and hierarchy
Uses instantaneous broadcast where the
receiver reacts immediately upon broadcast
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
Petri Nets
Consist of places, tokens, transitions,
and arcs
Well known for concurrency and
asynchronous nature
Lack hierarchical decomposition and
expressiveness for computations
2 Models of Petri Nets
Hierarchical Petri Nets (HPN)
PURE
Hierarchical Petri Nets
Inherit concurrency and asynchrony
Incorporate hierarchy for more complex
systems
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
Dataflow Graphs
5
Example:
X 4
Y
+
+
+
Control Step 1
Control Step 2
+
Control Step 3
Include nodes for computations and arcs for
the order of computations
Often used in modeling data-dominated
systems
Dataflow Models
Three models:
Dataflow Process Networks
Model Graph
Conditional Process Graph
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
Dataflow Process Networks
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
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
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
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
Synchronous/Reactive Models
Represent for reactive, real-time
systems
Produce outputs simultaneously with
input stimuli

No observable time delay in the reaction
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
ATM Network Interface Card
Application
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
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
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
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
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
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;
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
Example coding (cont.)
>;
Output:
>A;
Output:
>B;
Output:
>C;
Output: O
>R;
Output:
>A B C;
Output: O
Summary
Using representation models is very
important



Reduction in development cost
Reduction in design time
Performance enhancement
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”