PowerPoint 프레젠테이션 - German University in Cairo

Download Report

Transcript PowerPoint 프레젠테이션 - German University in Cairo

SoC Co-Design:
Co-Specification Models
Dr. Eng. Amr T. Abdel-Hamid
Spring 2009
System-On-a-Chip Design
ELECT 1002
SoC HW/SW Co-Design
SoC Design

Co-Specification (System Model Generation): Developing system sp

Co-Synthesis: Automatic and semi Automatic design of hardware and s
ecification that describes hardware software modules and relationship be
tween the hardware and software.
 Model the (embedded) system functionality from an abstract level.
 No concept of hardware or software.
 Common environment: SystemC: based on C++.
oftware modules to meet the specification


Dr. Amr Talaat
Partitioning:
 Dividing the functionality of an embedded system into units of co
mputation
Scheduling:
 Assign an execution start time to each task in a set, where tasks
are linked by some relations
ELECT1002
SoC HW/SW Co-Design
SoC Design


Allocation:
 Determining on which processing elements (PEs) some co
mputation will occur
 Select the number and type of communication links and pr
ocessing elements for the target system.
 Assignment (Mapping):
 Choosing particular component types for the allocated com
putation units
Co-Simulation and Co-verification
 Simultaneous simulation of hardware and software
Dr. Amr Talaat
ELECT1002
SOC Design Tasks
1. Model Generation (Co-Spec.)
SoC Design
Specification
model
2. Bus-arbitration model generation (Co-Spec.)
3. Protocol refinement (Co-Synthesis)
1
4. RTL synthesis (Co-Synthesis)
PE-assembly
model
System
Design
5. IP replacement (Co-Synthesis)
6. Interconnect network generation (Co-Synthesis)
2
Bus-arbitration
model
3
Time-accurate
Communication
model
Dr. Amr Talaat
4
Component
Design
ELECT1002
7. Co-Simulation???
5
Cycle-accurate
Computation
model
Implementation
model
6
Unified HW/SW Representation
SoC Design




Dr. Amr Talaat

A representation of a system that can be used to describe its
functionality independent of its implementation in hardware o
r software
Allows hardware/software partitioning to be delayed until trad
e-offs can be made
Typically used at a high-level in the design process
Provides a simulation environment after partitioning is done,
for both hardware and software designers to use to communi
cate
Supports cross-fertilization (Design Modifications) between h
ardware and software domains
ELECT1002
Hardware Software Model
SoC Design
 Uses a unified representation of the system to allow early
performance analysis
Dr. Amr Talaat
ELECT1002
Unified HW/SW Representation
SoC Design

System Models:






State-oriented models: Finite-state machine (FSM), Petri net
Activity-oriented models: Dataflow graph, Flowchart
Structure-oriented models: Block diagram, RT netlist, Gate netlist
Data-oriented models: Entity-relationship diagram, Jackson’s diag
ram
Heterogeneous models: FSM/dataflow graph, State charts, *Charts
.
Specification Languages:
Dr. Amr Talaat






UML
SystemC
SpecC
SystemVerilog
ESTEREL
SDL
ELECT1002
Models and Architectures
SoC Design
 Models are conceptual views of the system’s functionality
 Architectures are abstract views of the system’s implementati
on
 Model: a set of functional objects and rules for composing the
se objects
 Architecture: a set of implementation components and their c
onnections
Dr. Amr Talaat
ELECT1002
Example: An Elevator Controller Model
SoC Design
Dr. Amr Talaat
ELECT1002
Example: An Elevator Controller Architecture
SoC Design
Memory
I/O
CLC
Processor
Flip-Flops
Dr. Amr Talaat
I/O Ports
Hardware (RTL) Description
System Level
(General Purpose Proc.)
ELECT1002
System Models:
SoC Design





State-oriented models: Finite-state machine (FSM), Petri
net, ASMs
Activity-oriented models: Dataflow graph, Flowchart
Structure-oriented models: Block diagram, RT netlist, Gat
e netlist
Data-oriented models: Entity-relationship diagram, Jacks
on’s diagram
Heterogeneous models: FSM/dataflow graph, State chart
s, *Charts.
Dr. Amr Talaat
ELECT1002
Data Flow Diagram
SoC Design
W = Z * (X+Y)
 support hierarchy
 suitable for specifying complex
transformational systems
 inherent data dependencies
Dr. Amr Talaat
 do not express temporal behav
iors or control sequencing
 weak for modeling embedded
systems
ELECT1002
Heterogeneous: Data Control Flow Graphs
SoC Design



Graphs contain nodes corresponding to operations in either
hardware or software
Often used in high-level hardware synthesis
Can easily model data flow, control steps, and concurrent op
erations because of its graphical nature.
Pipeline Representation
Dr. Amr Talaat
ELECT1002
Finite State Machines
SoC Design

Reactive System
 continuously react to external and internal stimuli at their environme
nt’s speed e.g. telephones, automobiles, operating system, etc.
 To describe reactive behavior: states and events are good medium

Advantage
 used to describe and analyze control sequences
 yield better to analysis and synthesis than alternative control
models due to their finite nature
Dr. Amr Talaat
ELECT1002
State Transition Diagrams
SoC Design
 Used to visually represent an FSM
 Emphasis is on identifying states and possible transitions
 Circles represent States
 Arrows represent Transitions
Transitions
01/11
Initial State
S0
Input/Output
S1
01/01
11/10
Dr. Amr Talaat
State
ELECT1002
S3
1-/11
01/10
S2
011/00
State tables
SoC Design
 Table is another way to represent an FSM with an emphasis
on exploring all Event/State combinations
 Similar to the truth table
 Doesn’t contain the system clock when specifying its transi
tions (it is implicit that transitions occur only when allowed
by clock)
 Unless different stated, all the transitions are occurring on t
he positive edge of the clock
Dr. Amr Talaat
Present Inputs
State
ELECT1002
Next Outputs
State
FSM Example
SoC Design
 General Machine Description:
 deliver package of gum after 15 cents deposited
 single coin slot for dimes, nickels
 no change
N
Coin
Sensor D
Reset
Clk
Dr. Amr Talaat
ELECT1002
Vending
Machine
FSM
Open
Gum
Release
Mechanism
Vending Machine Example
SoC Design
Present
State
Reset
0¢
0¢
N
5¢
N
5¢
D
10¢
D
10¢
N, D
Dr. Amr Talaat
15¢
[open]
ELECT1002
15¢
Inputs
D N
0
0
1
1
0
0
1
1
0
0
1
1
X
0
1
0
1
0
1
0
1
0
1
0
1
X
Next
State
Output
Open
0¢
5¢
10¢
X
5¢
10¢
15¢
X
10¢
15¢
15¢
X
15¢
0
0
0
X
0
0
0
X
0
0
0
X
1
Mealy FSM
SoC Design
The FSM where the outputs are used immediately
X(t)
Q(t)
Y(t) = f(X(t), Q(t))
CLC
Q+(t)= g(X(t),Q(t))
Registers
CLK
Dr. Amr Talaat
t
t+1
t+2
Q(t+1) = Q+(t)
Synchronous FSM with immediate outputs
ELECT1002
Moore FSM
SoC Design
Each bit of the output is passed through a memory element.
X(t)
Q(t)
Y(t)
Y(t+1)
Registers
CLC
Q+(t)
CLK
Dr. Amr Talaat
t
t+1
t+2
Q(t+1) = Q+(t)
Synchronous FSM with delayed outputs
ELECT1002
Mealy FSM
SoC Design
 Output is dependent on the inputs and the current state
transition condition 1
/output 1
state 1
X(t)
Q(t)
state 2
transition condition 2
/output 2
Y(t)
CLC2
f
X(t)
Dr. Amr Talaat
Q(t)
Registers
Bank 1
CLC1
g
Clock
Q(t+1) = Q+(t)
ELECT1002
Mealy with
immediate output
Y(t) = f[X(t), Q(t)
Q+(t) = g[(X(t), Q(t)]
Q(t+1) = Q+(t)
Moore FSM
 Output is dependent only on the current state
SoC Design
transition
condition 1
state 1 /
output 1
transition
condition 2
state 2 /
output 2
X(t)
Q(t)
CLC1
g
Registers
Bank 1
Dr. Amr Talaat
Clock
Q(t+1) = Q+(t)
ELECT1002
Moore with
Q+(t) = g[(X(t), Q(t)]
Q(t+1) = Q+(t)
CLC2
f
Y(t+1)
Moore vs. Mealy FSM
SoC Design
 Moore and Mealy FSMs can be functionally equivalent
 Equivalent Mealy FSM can be derived from Moore FSM and vice ver
sa
 Mealy FSM Has Richer Description and usually requires smaller n
umber of states
 Smaller circuit area
 Mealy FSM computes Outputs as soon as Inputs change
 Mealy FSM responds one clock cycle sooner than equivalent
ore FSM
 Moore FSM has no combinational path between Inputs and
tputs
Dr. Amr Talaat
 Moore FSM is more likely to have a shorter critical path
ELECT1002
Mo
Ou
Mealy FSM - Example
SoC Design
 Mealy FSM that Recognizes Sequence “10”
0/0
1/0
S0
1/0
S1
0/1
Dr. Amr Talaat
Meaning of states:
 S0: No elements of the sequence observed
 S1: “1” observed
ELECT1002
Moore FSM - Example
SoC Design
 Moore FSM that Recognizes Sequence “10”
0
1
S0 / 0
reset
1
0
S1 / 0
1
S2 / 1
0
Dr. Amr Talaat
Meaning of states:
 S0: No elements of the sequence observed
 S1: “1” observed
 S2: “0” observed
ELECT1002
Finite State Machines
SoC Design
 Disadvantage
 Flat fashion, lots of states result in unstructured,
unrealistic, and chaotic state diagram (State Spa
ce Explosion)
 Not suitable for describing concurrent system
Dr. Amr Talaat
 Solution:
 Abstract State Machines (ASMs)
 Hierarchical Concurrent Finite State Machine
(HCFSM or State Charts)
 Hierarchical Finite State Machines with Multiple Conc
urrency Models (*Charts)
ELECT1002
Quake Example
SoC Design
 Types of behavior to capture:





Wander randomly if don’t see or hear an enemy
When see enemy -> attack
When hear an enemy -> search and chase
When die -> Spawn
If health is low and see an enemy ->retreat
 Extensions:
 When see power-ups during wandering -> collect them
 Exactly borrowed from John Laird and Mike van Lent’s GDC tutorial
Dr. Amr Talaat
ELECT1002
Example FSM
SoC Design
 States:
~E
Attack
E,~D
Wander
~E,~S,~D
S
E
~E
Dr. Amr Talaat
D
ELECT1002
E
D
E
Spawn
D
 E: enemy in sight
 S: sound audible
 D: dead
~S
D
S
 Events:
Chase
S,~E,~D
 E: see an enemy
 S: hear a sound
 D: die
 Action performed:
 On each transition
 On each update in some
states (e.g. attack)
Example FSM Problem
SoC Design
 States:
~E
Attack
E,~D
Wander
~E,~S,~D
Dr. Amr Talaat
ELECT1002
 Events:
S
E
~E
D
E
D
E
Spawn
D
 E: enemy in sight
 S: sound audible
 D: dead
~S
D
Chase
S,~E,~D
 E: see an enemy
 S: hear a sound
 D: die
S
Problem: Can’t go directly from
attack to chase. Why not?
Better Example FSM
SoC Design
~S
~E
Attack
E,~S,~D
D
E
Wander
~E,~S,~D
Dr. Amr Talaat
ELECT1002
D
S
E
~E
D
S
Spawn
D
~S
D
S
Attack-S
E,S,~D
~E
E
Chase
S,~E,~D
 States:
 E: enemy in sight
 S: sound audible
 D: dead
 Events:
 E: see an enemy
 S: hear a sound
 D: die
 Extra state to recall wh
ether or not heard a so
und while attacking
Example FSM with Retreat
SoC Design
Attack-ES
E,-D,S,-L
S
Attack-E
E,-D,-S,-L
-S
L
• States:
Retreat-S
-E,-D,S,L
L
-L
E
-E
E E
Wander-L
-E,-D,-S,L
L
-L
-L
E
L
Retreat-ES
E,-D,S,L
-S
-L
S
-E
Dr. Amr Talaat
Wander
-E E
-E,-D,-S,-L
D D
D
ELECT1002
D
Spawn
D
(-E,-S,-L)
S
Chase
-E,-D,S,-L
Retreat-E
E,-D,-S,L
–
–
–
–
E: enemy in sight
S: sound audible
D: dead
L: Low health
• Worst case: Each
extra state
variable can add
2n extra states
• n = number of
existing states
Hierarchical FSMs
SoC Design
 What if there is no simple action for a state?
 Expand a state into its own FSM, which explains what to do if in
that state
 Some events move you around the same level in the hierarchy, s
ome move you up a level
 When entering a state, have to choose a state for it’s child in the
hierarchy
 Set a default, and always go to that
 Or, random choice
 Depends on the nature of the behavior
Dr. Amr Talaat
ELECT1002
Hierarchical FSM Example
SoC Design
Wander
Attack
~E
E
~S
Pick-up
Powerup
Chase
S
Start
Turn Right
D
Spawn
~E
Dr. Amr Talaat
 Note: This is not a complete FSM
Go-through
Door
ELECT1002
 All links between top level states still
exist
 Need more states for wander
HCFSM (StateCharts)
SoC Design
 Extension of conventional FSMs by David Harel: (1987)
 Hierarchy
 Concurrency
 Communication
 StateCharts
Dr. Amr Talaat





Highly structured and economical description language
Compact
Expressive
Compositional
Modular
ELECT1002
StateCharts
SoC Design
Classical automata not useful for complex systems (comp
lex graphs cannot be understood by humans).
 Introduction of hierarchy  StateCharts [Harel, 1987]
StateChart = the only unused combination of “flow“ or “st
ate“ with “diagram“ or “chart“
Dr. Amr Talaat
ELECT1002
Introducing hierarchy
SoC Design
FSM will be in exactly on
e of the substates of S if
S is active
(either in A or in B or ..)
Dr. Amr Talaat
ELECT1002
StateCharts: Hierarchy
SoC Design

Dr. Amr Talaat
When a superstate is active, exactly one
of its substates is active
ELECT1002
Definitions
SoC Design
• Current states of FSMs are also called active states.
• States which are not composed of other states are called ba
sic states.
• States containing other states are called super-states.
• For each basic state s, the super-states containing s are cal
led ancestor states.
• Super-states S are called OR-super-states, if exactly one of
the sub-states of S is active whenever S is active.
Dr. Amr Talaat
superstate
ancestor state of E
ELECT1002
substates
OR States
SoC Design
Dr. Amr Talaat
•An OR-state can contain other states as its internal su
bstates (hierarchical internal structure);
• super OR-state is active, if and only if one of its imme
diate substates is active (exclusive or);
• When the control enters a (super) OR-state, its default
substate is entered and becomes active;
• When the control leaves a (super) OR-state, all its sub
states become inactive!
ELECT1002
Default state mechanism
SoC Design
Dr. Amr Talaat
Try to hide internal str
ucture from outside wo
rld!
 Default state
Filled circle
indicates sub-state ent
ered whenever super-s
tate is entered.
Not a state by itself!
ELECT1002
Combining history and default state mechanism
SoC Design
same meaning
Dr. Amr Talaat
ELECT1002
History mechanism
SoC Design
km
(behavior differe
nt from last slide
)
Dr. Amr Talaat
For input m, S enters the state it was in before S was left (c
an be A, B, C, D, or E). If S is entered for the very first time, t
he default mechanism applies.
History and default mechanisms can be used hierarchically.
ELECT1002
StateCharts: Concurrency
SoC Design
 And Decomposition: Orthogonal product of A and D
Dr. Amr Talaat
A = {B, C}
D = {E, F, G}
Y=AXD
ELECT1002
Concurrency
SoC Design
Convenient ways of describing concurrency are required.
AND-super-states: FSM is in all (immediate) sub-states of a
super-state; Example:
Dr. Amr Talaat
ELECT1002
And States
SoC Design
Dr. Amr Talaat
ELECT1002
Entering and leaving AND-super-states
SoC Design
incl.
Dr. Amr Talaat
Line-monitoring and key-monitoring are entered and left, w
hen service switch is operated.
ELECT1002
Timers
SoC Design
 Since time needs to be modeled in embedded systems,
 timers need to be modeled.
 In StateCharts, special edges can be used for timeouts.
Dr. Amr Talaat
If event a does not happen while the system is in the left
state for 20 ms, a timeout will take place.
ELECT1002
Using timers in answering machine
SoC Design
Dr. Amr Talaat
ELECT1002
Broadcast mechanism
SoC Design
Values of variables are visible to all parts of the State
Chart model.
New values become effective in phase 3 of the curren
t step and are obtained by all parts of the model in the f
ollowing step.
Dr. Amr Talaat
 StateCharts implicitly assumes a broadcast mechanis
m for variables.
 StateCharts is appropriate for local control systems (
), but not for distributed applications for which upda
ting variables might take some time ().
ELECT1002
StarCharts (*charts)
SoC Design
 Limitation on concurrency of HCFSM
 StateCharts loosely defines state transitions in concurrent FSM’
s to be simultaneous
 Broadcast mechanism
 Undetermined behavior on circular dependencies
 *Charts are models of computation supporting concurrency
better
 Loosely synchronized concurrency model
 Dataflow
Dr. Amr Talaat
 Tightly synchronized concurrency model
 Discrete Event
 Synchronous/Reactive (SR)
ELECT1002
*Charts
SoC Design
Dr. Amr Talaat
ELECT1002
Architectures
SoC Design
 Application-specific architectures
 Controller architecture,
 Datapath architecture,
 Finite-state machine with datapath (FSMD).
 Single-purpose processor
 General-purpose processors
Dr. Amr Talaat
Complex instruction set computer (CISC)
Reduced instruction set computer (RISC)
Vector machine
Very long instruction word computer (VLIW)
Parallel processors
ELECT1002
Processor technology
SoC Design
 Processors vary in their customization for the problem at hand
Desired
functionality
Dr. Amr Talaat
General-purpose
processor
ELECT1002
total = 0
for i = 1 to N loop
total += M[i]
end loop
Application-specific
processor
Single-purpose
processor
General-purpose processors
SoC Design
 Programmable device used in a variety of
applications
 Also known as “microprocessor”
 Features
 Program memory
 General datapath with large register file and
general ALU
Controller
Datapath
Control
logic and
State register
Register
file
IR
PC
General
ALU
 User benefits
 Low time-to-market and NRE costs
 High flexibility
Dr. Amr Talaat
 “Pentium” the most well-known, but there
are hundreds of others
Program
memory
Assembly code
for:
total = 0
for i =1 to …
ELECT1002
Data
memory
Single-purpose processors
SoC Design
 Digital circuit designed to execute exactly o
ne program
 a.k.a. coprocessor, accelerator or peripheral
 Features
 Contains only the components needed to exe
cute a single program
 No program memory
 Benefits
 Fast
 Low power
 Small size
Dr. Amr Talaat
ELECT1002
Controller
Datapath
Control
logic
index
total
State
register
+
Data
memory
Application-specific processors
SoC Design
 Programmable processor optimized for a p
articular class of applications having comm
on characteristics
 Compromise between general-purpose and
single-purpose processors
Controller
Datapath
Control
logic and
State register
Registers
 Features
 Program memory
 Optimized datapath
 Special functional units
 Benefits
Dr. Amr Talaat
 Some flexibility, good performance, size and
power
Custom
ALU
IR
PC
Program
memory
Assembly code
for:
total = 0
for i =1 to …
ELECT1002
Data
memory
Controller Architecture (Mealy FSM)
SoC Design
Dr. Amr Talaat
ELECT1002
Datapath architecture
SoC Design
Dr. Amr Talaat
ELECT1002
FSMD (FSM + DATA)
SoC Design
Dr. Amr Talaat
ELECT1002
Conclusion
SoC Design




Different models focus on different aspects
Proper model needs to represent system’s features
Models are implemented in architectures
Smooth transformation of models to architectures increases pr
oductivity
 Readings Assignment:
Dr. Amr Talaat
 D. Harel, "Statecharts: A Visual Formalism for Complex Systems", Sci. Comput. P
rogramming 8 (1987), 231-274. (Group: ??)
 Alain Girault, Bilung Lee, and Edward A. Lee, “Hierarchical Finite State Machines
with Multiple Concurrency Models”, IEEE Transactions On Computer-aided Desig
n Of Integrated Circuits And Systems, Vol. 18, No. 6, June 1999.
(Group: ??)
ELECT1002
References
SoC Design
 D. Harel, "Statecharts: A Visual Formalism for Complex Systems", Sci. Com
put. Programming 8 (1987), 231-274.
 Alain Girault, Bilung Lee, and Edward A. Lee, “Hierarchical Finite State Mach
ines with Multiple Concurrency Models”, IEEE Transactions On Computer-ai
ded Design Of Integrated Circuits And Systems, Vol. 18, No. 6, June 1999.
+ many others
Dr. Amr Talaat
ELECT1002