Вы находитесь на странице: 1из 216
SPECIFICATION AND DESIGN OF EMBEDDED SYSTEMS by Daniel D. Gajski Frank Vahid Sanjiv Narayan Jie
SPECIFICATION AND DESIGN
OF
EMBEDDED SYSTEMS
by
Daniel D. Gajski
Frank Vahid
Sanjiv Narayan
Jie Gong
University of California at Irvine
Department of Computer Science
Irvine, CA 92715-3425
1 of 214
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
UC Irvine
    Design representations Behavioral Represents functionality but not implementation Structural
 
 
 

Design representations

Behavioral

Represents functionality but not implementation

Structural

Represents connectivity but not dimensionality

Physical

Represents dimensionality but not functionality

 
   
   

2 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Introduction

Levels of abstraction Levels Behavioral forms Structural components P h y s i c a

Levels of abstraction

Levels of abstraction Levels Behavioral forms Structural components P h y s i c a l

Levels

Behavioral

forms

Structural

components

Physical

objects

Transistor

Gate

Register

Processor

Differential eq., current−voltage diagrams

Boolean equations, finite−state machines

Algorithms, flowcharts, instruction sets, generalized FSM

Executable spec., programs

Transistors,

resistors,

capacitors

Gates,

flip−flops

Adders, comparators, registers, counters, register files, queues

Processors, controllers, memories, ASICs

Analog and

digital cells

Modules,

units

Microchips,

ASICs

PCBs,

MCMs

digital cells Modules, units Microchips, ASICs PCBs, MCMs UC Irvine Introduction 3 of 214 Copyright (c)

UC Irvine

Introduction

3 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

Design methodologies Capture-and-simulate Schematic capture Simulation Describe-and-synthesize Hardware description
Design methodologies
Capture-and-simulate
Schematic capture
Simulation
Describe-and-synthesize
Hardware description language
Behavioral synthesis
Logic synthesis
Specify-explore-re ne
Executable speci cation
Software and hardware partitioning
Estimation and exploration
Speci cation re nement
Introduction
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
4 of 214
UC Irvine
Motivation Executable System specification implementation Processor Memory if (x = 0) then y = a
Motivation
Executable
System
specification
implementation
Processor
Memory
if
(x = 0) then
y = a * b / 2
Video
ASIC
I/O
accelerator
Partitioning
Models
Estimation
Languages
Refinement
Software compilation
Behavioral synthesis
Logic synthesis
Physical design
Test generation
Manufacturing
Introduction
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
5 of 214
UC Irvine
Outline Introduction Design models and architectures System-design languages An example Translation Partitioning
Outline
Introduction
Design models and architectures
System-design languages
An example
Translation
Partitioning
Estimation
Re nement
Methodology and environments
Outline
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
6 of 214
UC Irvine
Models and architectures Models Specification + Constraints (Specification) Design process Architectures
Models and architectures
Models
Specification + Constraints
(Specification)
Design
process
Architectures
Implementation
(Implementation)
Models are conceptual views of the system’s functionality
Architectures are abstract views of the system’s implementation
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
7 of 214
UC Irvine

Models and architectures Model: a set of functional objects and rules for composing these objects
Models and architectures Model: a set of functional objects and rules for composing these objects

Models and architectures

Models and architectures Model: a set of functional objects and rules for composing these objects Architecture:
Models and architectures Model: a set of functional objects and rules for composing these objects Architecture:

Model: a set of functional objects and rules for composing these objects

Architecture: a set of implementation components and their connections

8 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine
UC Irvine

UC Irvine

8 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

Models & Architectures

Models of an elevator controller "If the elevator is stationary and the floor requested is
Models of an elevator controller
"If the elevator is stationary and the floor
requested is equal to the current floor,
then the elevator remains idle.
If the elevator is stationary and the floor
requested is less than the current floor,
then lower the elevator to the requested floor.
If the elevator is stationary and the floor
requested is greater than the current floor,
then raise the elevator to the requested floor."
loop
if (req_floor = curr_floor) then
direction := idle;
elsif (req_floor < curr_floor) then
direction := down;
elsif (req_floor > curr_floor) then
direction := up;
end if;
end loop;
(a) English description
(b) Algorithmic model
(req_floor < curr_floor)
(req_floor = curr_floor)
(req_floor > curr_floor)
/
direction := down
/
direction := idle
/
direction := up
(req_floor < curr_floor)
(req_floor > curr_floor)
/
direction := down
/
direction := up
Down
Idle
Up
(req_floor = curr_floor)
(req_floor = curr_floor)
/
direction := idle
/
direction := idle
(req_floor < curr_floor)
/
direction := up
(req_floor < curr_floor)
/ direction := down
(c) State−machine model
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
9 of 214
UC Irvine
Architectures for implementing the elevator controller req_floor curr_floor State register Combinational logic (a)

Architectures for implementing the elevator controller

Architectures for implementing the elevator controller req_floor curr_floor State register Combinational logic (a)
req_floor curr_floor State register Combinational logic
req_floor
curr_floor
State register
Combinational logic

(a) Register level

direction

req_floor

curr_floor

logic (a) Register level direction req_floor curr_floor In/out ports direction Bus Processor Memory (b) System level
logic (a) Register level direction req_floor curr_floor In/out ports direction Bus Processor Memory (b) System level

In/out ports

Register level direction req_floor curr_floor In/out ports direction Bus Processor Memory (b) System level 10 of

direction

Bus

Processor

Memory

(b) System level

In/out ports direction Bus Processor Memory (b) System level 10 of 214 Copyright (c) 1994 Daniel
In/out ports direction Bus Processor Memory (b) System level 10 of 214 Copyright (c) 1994 Daniel

10 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

10 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

Models & Architectures

Models State-oriented models Finite-state machine (FSM), Petri net, Hierarchical concurrent FSM Activity-oriented
Models
State-oriented models
Finite-state machine (FSM), Petri net, Hierarchical concurrent FSM
Activity-oriented models
Data ow graph, Flowchart
Structure-oriented models
Block diagram, RT netlist, Gate netlist
Data-oriented models
Entity-relationship diagram, Jackson’s diagram
Heterogeneous models
Object-oriented paradigm, Program-state machine, Queueing model
Control/data ow
graph, Structure chart, Programming language paradigm,
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
11 of 214
UC Irvine
State oriented: Finite-state machine (Mealy model) r3/u2 r1/d2 r1/n r2/n r2/u1 start S S 2
State oriented: Finite-state machine (Mealy model)
r3/u2
r1/d2
r1/n
r2/n
r2/u1
start
S
S 2
1
r1/d1
S 3
r3/n
S
= { s1, s2, s3}
I = {r1, r2, r3}
O
= {d2, d1, n, u1, u2}
f:
S x I −> S
h: S x I −> O
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
12 of 214
UC Irvine
r2/d1
r3/u1
State oriented: Finite-state machine (Moore model) r1 r1 r3 r1 start /d2 S /d1 S
State oriented: Finite-state machine (Moore model)
r1
r1
r3
r1
start
/d2
S
/d1
S
/n
S 11
21
31
r2
r2
r2
r2
r1
r3
r3
r2
r1
r1
r3
/d1
/n
S
/u1
S 12
S 22
32
r1
r3
r1
r2
r3
r2
r2
r2
S
/n
S
/u1
S
/u2
13
23
33
r1
r3
r3
r3
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
13 of 214
UC Irvine
State oriented: Finite-state machine with datapath (curr_floor != req_floor) / output := req_floor − curr_floor;
State oriented: Finite-state machine with datapath
(curr_floor != req_floor) / output := req_floor − curr_floor; curr_floor := req_floor
start
S 1
(curr_floor = req_floor)
/ output := 0
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
14 of 214
UC Irvine
    Finite-state machines Merits: represent system’s temporal behavior explicitly suitable for
 
 
 

Finite-state machines

Merits:

represent system’s temporal behavior explicitly suitable for control-dominated system

 

Demerits:

lack of hierarchy and concurrency resulting in state or arc explosion when representing complex systems

 
 
 
 

15 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

State oriented: Petri nets p2 t4 p4 p1 t1 p5 t2 p3 Net = (P,
State oriented: Petri nets
p2
t4
p4
p1
t1
p5
t2
p3
Net = (P, T, I, O, u)
t3
P
= {p1, p2, p3, p4, p5}
T
= {t1, t2, t3, t4}
I:
I(t1) = {p1}
I(t2) = {p2,p3,p5}
I(t3) = {p3}
I(t4) = {p4}
O: O(t1) = {p5}
O(t2) = {p3,p5}
O(t3) = {p4}
O(t4) = {p2,p3}
u: u(p1) = 1
u(p2) = 1
u(p3) = 2
u(p4) = 0
u(p5) = 1
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
16 of 214
UC Irvine
  t1   Petri nets   t2 t 1 t2 t1     (a) Sequence
 
 

t1

t1   Petri nets  
 

Petri nets

t1   Petri nets  
t1   Petri nets  
 

t2

t1

t2 t 1 t2 t1  

t2

t1

 
 

(a) Sequence

(b) Branch

 

(c) Synchronization

 
t2
t2
 
t2      
 
t2      
t2      
 
(c) Synchronization   t2       t1   t1   t2 t3     t4

t1

 

t1

 
t2
t2

t3

   

t4

 
       
 
       
 
       
 
   

(d) Resource contention

 

(e) Concurrency

 
 
 

17 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Petri nets Merits: good at modeling and analyzing concurrent systems Demerits: ‘ incomprehensible when system
Petri nets
Merits:
good at modeling and analyzing concurrent systems
Demerits:
incomprehensible when system complexity increases
at’
model that is
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
18 of 214
UC Irvine
State oriented: Hierarchical concurrent FSM Y A D B E u a(P)/c r b F
State oriented: Hierarchical concurrent FSM
Y
A
D
B
E
u
a(P)/c
r
b
F
s
a
C
G
Models & Architectures
19 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
UC Irvine
    Hierarchical concurrent FSMs Merits: support both hierarchy and concurrency good for representing
 
 
 

Hierarchical concurrent FSMs

Merits:

support both hierarchy and concurrency good for representing complex systems

 

Demerits:

concentrate only on modeling control aspects and not data and activities

 
 
 
 

20 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Activity oriented: Data ow graphs (DFG) Y Z A 2.1 A 2.2 Input V’ W
Activity oriented: Data ow
graphs (DFG)
Y
Z
A 2.1
A 2.2
Input
V’
W
A 2.3
X
X
Z
Y
Z
A 1
A 2
Output
Y
+
*
W
W
V
V’
Output
File
(a) Activity level
(b) Operation level
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
21 of 214
UC Irvine
Data ow graphs Merits: support hierarchy suitable for specifying complex transformational systems represent
Data
ow
graphs
Merits:
support hierarchy
suitable for specifying complex transformational systems
represent problem-inherent data dependencies
Demerits:
do not express temporal behaviors or control sequencing
weak for modeling embedded systems
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
22 of 214
UC Irvine
Activity oriented: Flowchart (CFG) start J = 1 MAX = 0 J = J+1 No
Activity oriented: Flowchart (CFG)
start
J = 1
MAX = 0
J = J+1
No
No
Yes
J > N
MEM(J) > MAX
MAX = MEM(J)
Yes
end
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
23 of 214
UC Irvine
Flowcharts Merits: can impose a order to supersede natural data dependencies useful to represent tasks
Flowcharts
Merits:
can impose a order to supersede natural data dependencies
useful to represent tasks governed by control ow
Characteristics:
used only when the system’s computation is well known
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
24 of 214
UC Irvine
Structure oriented: Component-connectivity diagrams Left Right A B bus bus Register file LIR RIR ALU

Structure oriented: Component-connectivity diagrams

Structure oriented: Component-connectivity diagrams Left Right A B bus bus Register file LIR RIR ALU (b)
Left Right A B bus bus Register file LIR RIR ALU (b) RT netlist (c)
Left
Right
A
B
bus
bus
Register file
LIR
RIR
ALU
(b) RT netlist
(c) Gate netlist
Program Data memory memory System bus Processor Application I/O specific coprocessor hardware
Program
Data
memory
memory
System bus
Processor
Application
I/O
specific
coprocessor
hardware

(a) Block diagram

I/O specific coprocessor hardware (a) Block diagram 25 of 214 Copyright (c) 1994 Daniel D. Gajski,
I/O specific coprocessor hardware (a) Block diagram 25 of 214 Copyright (c) 1994 Daniel D. Gajski,

25 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

25 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

Models & Architectures

    Component-connectivity diagrams Merits: good at representing system’s structure  
 
 
 

Component-connectivity diagrams

Merits:

good at representing system’s structure

 

Characteristics:

 

often used in the later phases of design process

 
 
 
 

26 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Data oriented: Entity-relationship diagram Availability P.O. Supplier Product instance Customer Order Request
Data oriented: Entity-relationship diagram
Availability
P.O.
Supplier
Product
instance
Customer
Order
Request
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
27 of 214
UC Irvine
    Entity-relationship diagrams Merits: provide a good view of the data in the system,
 
 
 

Entity-relationship diagrams

Merits:

provide a good view of the data in the system, also suitable for expressing complex relations among various kinds of data

 

Demerits:

do not describe any functional or temporal behavior of the system.

 
 
 
 

28 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Data oriented: Jackson’s diagram Drawing AND * Color Shape Users OR Circle Rectangle Name AND
Data oriented: Jackson’s diagram
Drawing
AND
*
Color
Shape
Users
OR
Circle
Rectangle
Name
AND
Radius
Width
Height
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
29 of 214
UC Irvine
    Jackson’s diagrams Merits: suitable for representing data having a complex composite structure.
 
 
 

Jackson’s diagrams

Merits:

suitable for representing data having a complex composite structure.

 

Demerits:

do not describe any functional or temporal behavior of the system.

 
 
 
 

30 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Heterogeneous: Control/data ow graph Data flow graphs Read X Read W + Control flow graph
Heterogeneous: Control/data ow
graph
Data flow graphs
Read X
Read W
+
Control flow graph
Write A
start
stop
X
C
Const 3
Read X
1
2
E
W = 10
disable
+
S
A 1
0
enable
X := X + 2
A := X + 3
A := X + W
A := X + 5
W
start / enable A1 , enableA 2
Write A
Y
disable
S
1
enable
A
2
Read X
Const 2
Z
W = 10 / disable A
enable
1
,
A 3
+
Const 5
disable
S
enable
2
A 3
+
Control
Write X
Write A
(a) Activity level
(b) Operation level
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
31 of 214
UC Irvine
stop / disable A 2
disable,
A 3
Control/data ow graphs Merits: correct the inability of DFG in representing the control of a
Control/data
ow
graphs
Merits:
correct the inability of DFG in representing the control of a system
correct the inability of CFG to represent data dependencies
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
32 of 214
UC Irvine
Heterogeneous: Structure chart control Main Data A,B C A’,B’ A,B C,D A’,B’ Get Transform Compute
Heterogeneous: Structure chart
control
Main
Data
A,B
C
A’,B’
A,B
C,D
A’,B’
Get
Transform
Compute
Out_C
Branch
A
B
A
B
A’
B’
Get_A
Get_B
Change_A
Change_B
Do_Loop1
Do_Loop2
Iteration
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
33 of 214
UC Irvine
    Structure charts Merits: represent both data and control   Characteristics:  
 
 
 

Structure charts

Merits:

represent both data and control

 

Characteristics:

 

used in the preliminary stages of program design

 
 
 
 

34 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

  Heterogeneous: Programming languages   Imperative vs declarative programming languages: C, Pascal,
 
 

Heterogeneous: Programming languages

 

Imperative vs declarative programming languages:

C, Pascal, Ada, C++, etc. LISP, PROLOG, etc.

Sequential vs concurrent programming languages:

Pascal, C, etc. CSP, ADA, VHDL, etc.

 
 
 

35 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Programming languages Merits: model data, activity, and control Demerits: do not explicitly model the system’s
Programming languages
Merits:
model data, activity, and control
Demerits:
do not explicitly model the system’s states
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
36 of 214
UC Irvine
Heterogeneous: Object-oriented paradigm Object Object Object Data Data Data Operations Operations Operations
Heterogeneous: Object-oriented paradigm
Object
Object
Object
Data
Data
Data
Operations
Operations
Operations
Transformation
function
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
37 of 214
UC Irvine
    Object-oriented paradigms Merits: support information hiding, inheritance, natural concurrency
 
 
 

Object-oriented paradigms

Merits:

support information hiding, inheritance, natural concurrency

 

Demerits:

not suitable for systems with complicated transformation functions

 
 
 
 

38 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Heterogeneous: Program-state machine variable A: array[1 20] of integer Y A D variable i, max:
Heterogeneous: Program-state machine
variable A: array[1
20]
of integer
Y
A
D
variable
i, max: integer ;
B
max = 0;
for
i = 1 to 20 do
( A[i] >
max
end if;
end for
if
e1
e2
max ) then
= A[i] ;
C
e3
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
39 of 214
UC Irvine

Program-state machines Merits: represent system’s states, data, control and activities in a single model overcome

Program-state machines

Program-state machines Merits: represent system’s states, data, control and activities in a single model overcome the

Merits:

represent system’s states, data, control and activities in a single model overcome the limitations of programming languages and HCFSM models

the limitations of programming languages and HCFSM models UC Irvine Models & Architectures 40 of 214

UC Irvine

Models & Architectures

40 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

Heterogeneous: Queueing model Queue Server Arriving requests (a) One server Arriving requests (b) Multiple servers
Heterogeneous: Queueing model
Queue Server
Arriving
requests
(a) One server
Arriving
requests
(b) Multiple servers
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
41 of 214
UC Irvine
Queueing model Characteristics: used for analyzing system’s performance, and can nd utilization, queueing length,
Queueing model
Characteristics:
used for analyzing system’s performance, and
can nd
utilization, queueing length, throughput
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
42 of 214
UC Irvine
    Architectures   Application-speci c architectures Controller architecture, Datapath
 
 
 

Architectures

 

Application-speci c architectures

Controller architecture, Datapath architecture, Finite-state machine with datapath (FSMD).

General-purpose processors

Complex instruction set computer (CISC) Reduced instruction set computer (RISC) Vector machine Very long instruction word computer (VLIW)

Parallel processors

 
 
 

43 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Models & Architectures

Controller architecture State register Next−state Output Outputs function function Inputs Models &
Controller architecture
State register
Next−state
Output
Outputs
function
function
Inputs
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
44 of 214
UC Irvine
Datapath architecture x(i) b(0) x(i−1) b(1) x(i−2) b(2) x(i−3) b(3) * * * * +
Datapath architecture
x(i) b(0)
x(i−1) b(1)
x(i−2) b(2)
x(i−3) b(3)
*
*
*
*
+
+
+
Pipeline stages
y(i)
(a) Three stage pipeline
x(i) b(0)
x(i−1)
b(1)
x(i−2) b(2)
x(i−3)
b(3)
*
*
*
*
+
+
+
y(i)
Pipeline stages
(b) Four stage pipeline
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
45 of 214
UC Irvine
FSMD Datapath inputs State register Control Next−state Output Datapath function function Status Control unit
FSMD
Datapath inputs
State register
Control
Next−state
Output
Datapath
function
function
Status
Control unit
Datapath outputs
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
46 of 214
UC Irvine
CISC architecture Control Microprogram memory Datapath PC MicroPC +1 Address Status selection logic Memory
CISC architecture
Control
Microprogram
memory
Datapath
PC
MicroPC
+1
Address
Status
selection
logic
Memory
Instruction reg.
Control unit
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
47 of 214
UC Irvine
RISC architecture Datapath Register file Control Hardwired output and next−state logic ALU Data State
RISC architecture
Datapath
Register
file
Control
Hardwired
output and
next−state
logic
ALU
Data
State register
cache
Status
Instr.
Instruction reg.
cache
Memory
Control unit
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
48 of 214
UC Irvine
Vector machines Interleaved memory Memory Memory pipes pipes Vector Scalar registers registers Vector Scalar
Vector machines
Interleaved memory
Memory
Memory
pipes
pipes
Vector
Scalar
registers
registers
Vector
Scalar
functional
functional
unit
unit
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
49 of 214
UC Irvine
VLIW architecture Memory Register file + + ** Models & Architectures 50 of 214 Copyright
VLIW architecture
Memory
Register file
+
+
**
Models & Architectures
50 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
UC Irvine
Parallel processors: SIMD/MIMD PE 0 PE PE 1 N−1 Proc. 0 Proc. 1 Proc. N−1
Parallel processors: SIMD/MIMD
PE 0
PE
PE
1
N−1
Proc. 0
Proc. 1
Proc. N−1
Control
unit
Mem. 0
Mem. 1
Mem. N−1
Interconnection network
(a) Message passing
Proc. 0
Proc. 1
Proc. N−1
Interconnection network
Mem. 0
Mem. 1
Mem. N−1
(b) Shared memory
Models & Architectures
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
51 of 214
UC Irvine

Conclusion Different models focus on different aspects Proper model needs to represent system’s features Models
Conclusion Different models focus on different aspects Proper model needs to represent system’s features Models

Conclusion

Conclusion Different models focus on different aspects Proper model needs to represent system’s features Models are
Conclusion Different models focus on different aspects Proper model needs to represent system’s features Models are

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 productivity

52 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

52 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

Models & Architectures

System speci cation For every design, there exists a conceptual view Conceptual view depends on
System speci cation
For every design, there exists a conceptual view
Conceptual view depends on application
Computation : conceptualized as a program
Controller : conceptualized as a state-machine
Goal of speci cation
language
Capture conceptual view with minimum designer effort
Ideal language
1-to-1 mapping between conceptual model & language constructs
53 of 214
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
UC Irvine
Outline Characteristics of commonly used conceptual models: Concurrency, hierarchy, synchronization Requirements for
Outline
Characteristics of commonly used conceptual models:
Concurrency, hierarchy, synchronization
Requirements for embedded system speci cation
Evaluate HDLs with respect to embedded systems
VHDL, Verilog, Esterel, CSP, Statecharts, SDL, SpecCharts
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
54 of 214
UC Irvine
Concurrency Behavior: a chunk of system functionality e.g. process, procedure, state-machine System often
Concurrency
Behavior: a chunk of system functionality
e.g. process, procedure, state-machine
System often conceptualized as set of concurrent behaviors
Concurrency can exist at different abstraction levels:
Job-level
Task-level
Statement-level
Operation-level
Bit-level
Two types of concurrency within a behavior
Data-driven, Control-driven
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
55 of 214
UC Irvine
Data-driven concurrency Operations execute when input data is available Execution order determined by data dependencies
Data-driven concurrency
Operations execute when input data is available
Execution order determined by data dependencies
A
B
C
D
X
add
subtract
1:
2:
multiply
3:
Q = A + B
Y = X + P
P = (C − D) * Q
add
Q
P
Y
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
56 of 214
UC Irvine
Control-driven concurrency Control thread : set of operations executed sequentially Concurrency represented by multiple
Control-driven concurrency
Control thread : set of operations executed sequentially
Concurrency represented by multiple control threads
Q
Fork-join statement
sequential behavior X
begin
Q();
A
B
C
fork
A(); B(); C(); join;
R();
end behavior X;
R
Process statement
concurrent behavior X
begin
process A();
process B();
process C();
end behavior X;
A
B
C
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
57 of 214
UC Irvine
State-transitions Systems often are state-based, e.g. controllers State may represent mode or stage of being
State-transitions
Systems often are state-based, e.g. controllers
State may represent
mode or stage of being
computation
Dif cult to capture using programming constructs
u
v
P
w
z
start
Q
R
T
finish
x
y
S
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
58 of 214
UC Irvine
    Hierarchy Required for managing system complexity   Allows system modeler to focus on
 
 
 

Hierarchy

Required for managing system complexity

 

Allows system modeler to focus on one subsystem at a timeHierarchy Required for managing system complexity   Enhances comprehension of system functionality Scoping

Enhances comprehension of system functionalityAllows system modeler to focus on one subsystem at a time Scoping mechanism for objects like

Scoping mechanism for objects like types and variablesat a time Enhances comprehension of system functionality Two types of hierarchy   Structural hierarchy

Two types of hierarchy

 

Structural hierarchylike types and variables Two types of hierarchy   Behavioral hierarchy     c a t

Behavioral hierarchyTwo types of hierarchy   Structural hierarchy     c a t i o n 59

 
 
 

cation

59 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

System speci

Structural hierarchy System represented as set of interconnected components Interconnections between components
Structural hierarchy
System represented as set of interconnected components
Interconnections between components represent wires
Several levels: systems, chips, RT-components, gates
System
Processor
Control Logic
Datapath
data bus
Memory
control
lines
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
60 of 214
UC Irvine

Behavioral hierarchy Ability to successively decompose behavior into sub-behaviors behavior P variable x, y; begin
Behavioral hierarchy Ability to successively decompose behavior into sub-behaviors behavior P variable x, y; begin
Behavioral hierarchy Ability to successively decompose behavior into sub-behaviors behavior P variable x, y; begin
Behavioral hierarchy
Ability to successively decompose behavior into sub-behaviors
behavior P
variable x, y;
begin
Q(x) ;
R(y) ;
end behavior P;
Concurrent decomposition
Fork-join
P
Process
Q
e4
R
Sequential decomposition
e5
Q1
R1
e2
Procedure
e1
e8
State-machine
Q3
e6
Q2
e3
R2
e7
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
61 of 214
UC Irvine

System speci

Programming constructs Some behaviors easily conceptualized as sequential algorithms Wide variety of constructs available

Programming constructs

Programming constructs Some behaviors easily conceptualized as sequential algorithms Wide variety of constructs available

Some behaviors easily conceptualized as sequential algorithms

Wide variety of constructs available

Assignment, branching, iteration, subprograms, recursion, complex data types (records, lists)

type

variable buf : buffer_type; variable i, j : integer;

for i = 1 to 10 for j = i to i if (buf(i) > buf(j)) then SWAP(buf(i), buf(j)); end if; end for; end for;

buffer_type is array (1 to 10) of integer;

end for; end for; buffer_type is array (1 to 10) of integer; UC Irvine System speci

UC Irvine

System speci

62 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

cation

Behavioral completion Behavior completes when all computations performed Advantages Behavior can be viewed without
Behavioral completion
Behavior completes when all computations performed
Advantages
Behavior can be viewed without inter-level transitions
Allows natural decomposition into sequential subbehaviors
B
Y
X
q 1
X1
e5
Y1
start
final
q 0
e3
q 3
X3
state
e1
Y2
q
e2
X2
e4
2
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
63 of 214
UC Irvine
Communication shared memory Concurrent behaviors exchange data process P process Q Shared-memory model Sender
Communication
shared memory
Concurrent behaviors exchange data
process P
process Q
Shared-memory model
Sender updates common medium
Persistent, Non-persistent
Message-passing model
process Q
process P
Data sent over abstract channels
begin
begin
Unidirectional / bidirectional
variable x
variable y
channel
Point-to-point / multiway
C
send (x);
receive (y);
Blocking / non-blocking
end
end
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
64 of 214
UC Irvine
Synchronization Concurrent behaviors execute at different speeds Synchronization required when Data exchanged between
Synchronization
Concurrent behaviors execute at different speeds
Synchronization required when
Data exchanged between behaviors
Different activities must be performed simultaneously
Two types of synchronization mechanisms
Control-dependent
Data-dependent
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
65 of 214
UC Irvine
Control-dependent synchronization Synchronization based on control structure of behavior Q behavior X begin Fork-join
Control-dependent synchronization
Synchronization based on control structure of behavior
Q
behavior X
begin
Fork-join
Q();
A
B
C
fork
A(); B(); C(); join;
R();
synchronization
end
behavior X;
point
R
Reset
AB
ABC
B
C
A
B
A
B1
A1
A2
B2
e
e
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
66 of 214
UC Irvine

Data-dependent synchronization Synchronization based on communication of data between behaviors AB A B A1 B1
Data-dependent synchronization Synchronization based on communication of data between behaviors AB A B A1 B1

Data-dependent synchronization

Data-dependent synchronization Synchronization based on communication of data between behaviors AB A B A1 B1 x:=0
Data-dependent synchronization Synchronization based on communication of data between behaviors AB A B A1 B1 x:=0

Synchronization based on communication of data between behaviors

AB A B A1 B1 x:=0 e (x=1) A2 B2 x:=1
AB
A
B
A1
B1
x:=0
e
(x=1)
A2
B2
x:=1

Synchronization by common variable

AB A B A1 B1 e e A2 B2 Synchronization by common event
AB
A
B
A1
B1
e
e
A2
B2
Synchronization by
common event
AB A B A1 B1 e entered A2 A2 B2 Synchronization by status detection
AB
A
B
A1
B1
e
entered A2
A2
B2
Synchronization by
status detection

cation

67 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

c a t i o n 67 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank

System speci

Exception handling Occurrence of event terminates current computation Control transferred to appropriate next mode
Exception handling
Occurrence of event terminates current computation
Control transferred to appropriate next mode
Example of exceptions: interrupts, resets
P
P1
e
Q
P2
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
68 of 214
UC Irvine
Timing Required to represent real world implementations Functional timing: affects simulation of system speci cation
Timing
Required to represent real world implementations
Functional timing: affects simulation of system speci cation
wait for 200 ns;
A <= A + 1 after 100 ns;
Timing constraints: guide synthesis and veri cation tools
min 50 ns
behavior Q
IN
behavior
max 10 ms
B
channel C
(max 10 Mb/s)
OUT
behavior P
time
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
69 of 214
UC Irvine
Embedded system speci cation Embedded system: behavior de ned by interaction with environment Essential characteristics
Embedded system speci cation
Embedded system: behavior de ned by interaction with environment
Essential characteristics
State-transitions
Behavioral hierarchy
Programming constructs
Exceptions
Concurrency
Behavioral completion
start
P
P
P1
fork
u
P
P2
v
Q
R
e
Q
w
join
Q
R
x
S
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
70 of 214
UC Irvine
VHDL IEEE standard, intended for documentation and exchange of designs [IEE88] Characteristics supported Behavioral
VHDL
IEEE standard, intended for documentation
and exchange of designs [IEE88]
Characteristics supported
Behavioral hierarchy : single level of processes
Structural hierarchy : nested blocks and component instantiations
Concurrency : task-level (process), statement-level (signal assignment)
Programming constructs
Communication : shared-memory using global signals
Synchronization : wait on and wait until statements
Timing : wait for statement, after clause in assignments
Characteristics not supported
Exceptions : partially supported by guarded signal assignments
State transitions
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
71 of 214
UC Irvine
Verilog and Esterel Verilog [TM91] developed as proprietary language for speci cation, simulation Esterel [Hal93]
Verilog and Esterel
Verilog [TM91] developed as proprietary language
for speci cation, simulation
Esterel [Hal93] developed for speci cation
of reactive systems
Characteristics supported:
Behavioral hierarchy : fork-join
Structural hierarchy : hierarchy of interconnected modules
Programming constructs
Communication : shared registers (Verilog) and broadcasting (Esterel)
Synchronization : wait for an event on a signal
Timing : modeling of gate, net, assignment delays in Verilog
Exceptions : disable (Verilog), watching, do-upto, trap statements (Esterel)
Characteristics not supported: State transitions
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
72 of 214
UC Irvine
SDL (Speci cation and Description language) system CCITT standard in telecommunication for protocol speci cation
SDL (Speci cation
and Description language)
system
CCITT standard in telecommunication
for protocol speci cation [BHS91]
block
signal route
process
Characteristics supported
Behavioral hierarchy : nested data ow
process
Structural hierarchy : nested blocks
signal route
State transitions : state machine in processes
Communication : message passing
channel
Timing : timeouts generated by timer object
channel
block
Characteristics not supported
Exceptions
channel
Programming constructs
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
73 of 214
UC Irvine
CSP (Communicating Sequential Processes) Intended to specify programs running on multiprocessor machines [Hoa78]
CSP (Communicating Sequential Processes)
Intended to specify programs running on
multiprocessor machines [Hoa78]
Characteristics supported
Behavioral hierarchy : fork-join using parallel command
Programming constructs
Communication : message passing using input, output commands
Synchronization : blocking message passing
Characteristics not supported
Exceptions
State transitions
Structural hierarchy
Timing
System speci
cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
74 of 214
UC Irvine

SpecCharts Developed for embedded system speci cation [NVG92] PSM (program-state machine) model + VHDL Characteristics
SpecCharts Developed for embedded system speci cation [NVG92] PSM (program-state machine) model + VHDL Characteristics

SpecCharts

SpecCharts Developed for embedded system speci cation [NVG92] PSM (program-state machine) model + VHDL Characteristics

Developed for embedded system speci cation [NVG92]

PSM (program-state machine) model + VHDL

Characteristics supported

E port P, Q : in integer;

B type INTARRAY is array (natural range <>) of integer; signal A : INTARRY (15
B
type INTARRAY is array
(natural range <>) of integer;
signal A : INTARRY (15 downto 0);
X
Y
X1
variable
MAX : integer ;
MAX := 0;
e1
for J
in 0 to 15 loop
if
( A(J) >
MAX ) then
X2
max := A(J) ;
end if;
end loop
e2
e3

Behavioral hierarchy : sequential/concurrent behaviorsMAX ) then X2 max := A(J) ; end if; end loop e2 e3 State transitions:

State transitions: TOC (transition on completion) arcs Communication : shared memory, message passinge3 Behavioral hierarchy : sequential/concurrent behaviors Exceptions : TI (transition immediately) arcs

Exceptions : TI (transition immediately) arcsarcs Communication : shared memory, message passing Characteristics similar to VHDL Programming constructs

Characteristics similar to VHDL

Programming constructsimmediately) arcs Characteristics similar to VHDL Structural hierarchy Synchronization and Timing c a t i

Structural hierarchy Synchronization and Timingarcs Characteristics similar to VHDL Programming constructs c a t i o n 75 of 214

constructs Structural hierarchy Synchronization and Timing c a t i o n 75 of 214 Copyright

cation

75 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

c a t i o n 75 of 214 Copyright (c) 1994 Daniel D. Gajski, Frank

System speci

SpecCharts : state transitions State transitions represented by TOC and TI arcs between behaviors start
SpecCharts : state transitions
State transitions represented by TOC and TI arcs between behaviors
start
behavior MAIN
begin
type sequential subbehaviors is
P
P
: : : (TOC,
Q)
u
Q
(TOC, u,
v, Q);
P), ; (TOC, w, R);
R
(TOC,
x,
v
Q
behavior P
behavior R
Q
w
behavior
x
end MAIN;
R
System speci cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
76 of 214
UC Irvine
SpecCharts : behavioral hierarchy Hierarchy represented by nested behaviors Behavior decomposed into sequential or
SpecCharts : behavioral hierarchy
Hierarchy represented by nested behaviors
Behavior decomposed into sequential or concurrent subbehaviors
behavior MAIN
type sequential subbehaviors is
begin
true, true,
Q_R);
P
: (TOC,
S);
S Q_R P
: : ; (TOC,
behavior P
fork
behavior Q_R
type concurrent subbehavior is
begin
Q : : (TOC,
(TOC, true,
true, halt);
halt);
Q
R
R
behavior Q
R
join
end behavior
Q_R;
S
end behavior
MAIN;
S
System speci cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
77 of 214
UC Irvine
SpecCharts : exceptions Exceptions represented by TI (transition immediately) arcs behavior MAIN begin type sequential
SpecCharts : exceptions
Exceptions represented by TI (transition immediately) arcs
behavior MAIN
begin
type sequential subbehaviors is
P
P
e, Q);
P1
Q
: : (TI,
;
P2
behavior
P
behavior
P1
e
behavior P2
Q
behavior Q
end MAIN;
System speci cation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
78 of 214
UC Irvine
    Summary   Language   Embedded System Features       State Behavioral
 
 
 

Summary

 

Language

 

Embedded System Features

   
 

State

Behavioral

Concurrency

Program

Exceptions

Behavioral

 

Transitions

Hierarchy

Constructs

Completion

VHDL

 
VHDL  
VHDL  
VHDL  
VHDL  
VHDL  
VHDL  

Verilog

Verilog
Verilog
Verilog
Verilog
Verilog
Verilog

Esterel

Esterel
Esterel
Esterel
Esterel
Esterel
Esterel

SDL

SDL
SDL
SDL
SDL
SDL
SDL

CSP

CSP
CSP
CSP
CSP
CSP
CSP

Statecharts

Statecharts
Statecharts
Statecharts
Statecharts
Statecharts
Statecharts

SpecCharts

SpecCharts
SpecCharts
SpecCharts
SpecCharts
SpecCharts
SpecCharts
Feature

Feature

fully

Feature fully Feature partially Feature not  

Feature partially

Feature fully Feature partially Feature not  

Feature not

 

supported

supported

supported

 
 

cation

79 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

System speci

Speci cation example An executable speci cation-language enables: Early veri cation Precision Automation
Speci cation example
An executable speci cation-language
enables:
Early veri cation
Precision
Automation
Documentation
A good language/model match reduces:
Capture time
Comprehension time
Functional errors
80 of 214
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
UC Irvine
Outline Capture an example’s model in a particular language PSM model in the SpecCharts language
Outline
Capture an example’s model in a particular language
PSM model in the SpecCharts language
Point out the bene ts
of a good language/model match
Highlight experiments that demonstrate those bene ts
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
81 of 214
UC Irvine
Answering machine controller’s environment phone line Announcement Tape Line unit unit circuitry tollsaver
Answering machine controller’s environment
phone line
Announcement
Tape
Line
unit
unit
circuitry
tollsaver
messages
power
rec
ann
light
Controller
hear
ann
on/off
memo
play
msgs
stop
rew
play
fwd
mic
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
82 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
Highest-level view of the controller Controller SystemOff power=’0’ power=’1’ SystemOn phone line
Highest-level view of the controller
Controller
SystemOff
power=’0’
power=’1’
SystemOn
phone line
Announcement
Tape
Line
unit
unit
circuitry
tollsaver
messages
power
rec
ann
light
Controller
hear
ann
on/off
memo
play
msgs
stop
rew
play
fwd
mic
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
83 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
The SystemOn behavior SystemOn System usually responds to the line RespondToLine rising(any_button_pushed) Pressing
The SystemOn behavior SystemOn System usually responds to the line RespondToLine rising(any_button_pushed) Pressing
The SystemOn behavior
SystemOn
System usually responds
to the line
RespondToLine
rising(any_button_pushed)
Pressing any machine button
gets immediate response
RespondToMachineButton
phone line
Announcement
Tape
Line
unit
unit
circuitry
tollsaver
messages
power
rec
ann
light
Controller
hear
ann
on/off
memo
play
msgs
stop
rew
play
fwd
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
84 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
mic
mic
The RespondToMachineButton behavior RespondToMachineButton behavior RespondToMachineButton type code is begin if
The RespondToMachineButton behavior
RespondToMachineButton
behavior RespondToMachineButton
type code is
begin
if (play=’1’) then
HandlePlay;
elsif (fwd=’1’) then
HandleFwd;
elsif (rew=’1’) then
HandleRew;
elsif (memo=’1’) then
HandleMemo;
elsif (stop=’1’) then
HandleStop;
elsif (hear_ann=’1’) then
HandleHearAnn;
elsif (rec_ann=’1’) then
HandlePlay
play=’1’
HandleFwd
fwd=’1’
HandleRew
rew=’1’
HandleMemo
memo=’1’
HandleStop
stop=’1’
phone line
HandleRecAnn;
elsif (play_msgs=’1’) then
HandleHearAnn
hear_ann=’1’
Announcement
Tape
Line
unit
unit
circuitry
HandlePlayMsgs;
end if;
end;
HandleRecAnn
rec_ann=’1’
tollsaver
messages
HandlePlayMsgs
power
play_msgs=’1’
rec
ann
light
Controller
hear
(a)
(b)
ann
on/off
memo
play
msgs
stop
rew
play
fwd
mic
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
85 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
The RespondToLine behavior Monitors line for rings Answers line RespondToLine Responds to exceptions Monitor Hangup
The RespondToLine behavior
Monitors line for rings
Answers line
RespondToLine
Responds to exceptions
Monitor
Hangup
rising(hangup)
Machine turned off
falling(machine_on)
phone line
Answer
Announcement
Tape
Line
unit
unit
circuitry
tollsaver
messages
power
rec
ann
light
Controller
hear
ann
on/off
memo
play
msgs
stop
rew
play
fwd
mic
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
86 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
The Monitor behavior Monitor Counts for required rings signal rings_to_wait : integer range 1 to
The Monitor behavior
Monitor
Counts for
required rings
signal rings_to_wait : integer range 1 to 20 := 4;
function DetermineRingsToWait return integer is begin
if ((num_msgs > 0) and (tollsaver=’1’) and (machine_on=’1’)) then
return(2);
elsif (machine_on=’1’) then
return(4);
else
return(15);
end if;
Requirements
may change
end;
MaintainRingsToWait
phone line
CountRings
variable I : integer range 0 to 20;
Announcement
Tape
Line
unit
unit
circuitry
tollsaver
messages
power
loop
rings_to_wait <= DetermineRingsToWait;
wait on tollsaver, machine_on;
end loop;
rec
ann
light
Controller
hear
ann
on/off
i := 0;
while (i < rings_to_wait) loop
wait on rings_to_wait, ring;
if (rising(ring)) then
i := i + 1;
end if;
end loop;
memo
play
msgs
stop
rew
play
fwd
mic
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
87 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
The Answer behavior Answer rising(hangup) PlayAnnouncement RecordMsg Hangup button="0001"
The Answer behavior
Answer
rising(hangup)
PlayAnnouncement
RecordMsg
Hangup
button="0001"
button="0001"
RemoteOperation
(a)
behavior PlayAnnouncement type code is
begin
ann_play <= ’1’;
wait until ann_done = ’1’;
ann_play <= ’0’;
end;
behavior RecordMsg type code is
begin
ProduceBeep(1 s);
if (hangup = ’0’) then
tape_rec <= ’1’;
wait until hangup=’1’ for 100 s;
ProduceBeep(1 s);
num_msgs <= num_msgs + 1;
tape_rec <= ’0’;
end if;
end;
(b)
(c)
phone line
Announcement
Tape
Line
unit
unit
circuitry
tollsaver
messages
power
rec
ann
light
Controller
hear
ann
on/off
memo
play
msgs
stop
rew
play
fwd
mic
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
88 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
The RemoteOperation behavior Owner can operate machine remotely by phone Owner identi es himself by
The RemoteOperation behavior
Owner can operate machine remotely by phone
Owner identi es
himself by four button ID
RemoteOperation
hangup=’1’
CheckCode
code_ok=’0’
code_ok=’1’
RespondToCmds
behavior CheckUserCode type code is
begin
code_ok <= true;
for (i in 1 to 4) loop
wait until tone /= "1111" and tone’event;
if (tone /= user_code(i)) then
code_ok <= false;
end if;
end loop;
end;
(a)
(b)
phone line
Announcement
Tape
Line
unit
unit
circuitry
tollsaver
messages
power
rec
ann
light
Controller
hear
ann
on/off
memo
play
msgs
stop
rew
play
fwd
mic
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
89 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
The answering machine controller speci cation Controller SystemOff phone line power=’1’ power=’0’ SystemOn
The answering machine controller speci cation
Controller
SystemOff
phone line
power=’1’
power=’0’
SystemOn
InitializeSystem
RespondToMachineButton
Announcement
Tape
Line
unit
unit
circuitry
rising(any_button_pushed)
RespondToLine
Monitor
rising(hangup)
falling(machine_on)
tollsaver
Answer
messages
rising(hangup)
power
PlayAnnouncement
RecordMsg
Hangup
rec
tone="0001"
ann
light
RemoteOperation
Controller
hangup=’1’
hear
CheckUserCode
ann
on/off
code_ok
not code_ok
memo
RespondToCmds
tone="0010"
play
HearMsgsCmds
MiscCmds
msgs
stop
rew
play
fwd
hangup=’1’
other
mic
ResetTape
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
90 of 214
UC Irvine
ann_rec
ann_play
ann_done
tape_rec
tape_play
tape_fwd
tape_rew
tape_cnt
tone
hangup
ring
offhook
beep
Executable speci cation use Precision Readability/precision compete in a natural language Executable speci cation
Executable speci cation use
Precision
Readability/precision compete in a natural language
Executable speci cation encourages precision
Designer asks questions, speci cation answers them
Language/model match (SpecCharts/PSM):
Hierarchy
State-transitions
Programming constructs
Concurrency
Exceptions
Completion
Equivalence of states and programs
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
91 of 214
UC Irvine
Speci cation capture experiment VHDL SpecCharts Average specification−time in minutes Number of modelers Number of
Speci cation capture experiment
VHDL
SpecCharts
Average specification−time in minutes
Number of modelers
Number of incorrect specifications first time
Number of incorrect specifications second time
40
16
3
3
2
0
1
0
VHDL modelers required 2.5 times longer
Two VHDL speci cations
possessed control errors
SpecCharts were effective for state-transitions and exceptions
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
92 of 214
UC Irvine
  Comparison of SpecCharts, VHDL and Statecharts     Answering machine example   Conceptual
 
 

Comparison of SpecCharts, VHDL and Statecharts

 
 

Answering machine example

 

Conceptual

VHDL

VHDL

Statecharts

 
 

model

SpecCharts

(hierarch.)

(flat)

 

Specification attributesShortcomings

Program−states

42

42

42

32

80

Arcs

40

40

40

152

135

Control signals

−−

0

84

1

0

Lines/leaf

−−

7

27

29

−−

Lines

−−

446

1592

963

−−

Words

−−

1733

6740

8088

−−

 

No sequential program constructs

 

X

No hierarchy

 

X

X

No exception

 

constructs

X

X

No hierarchical

 

events

X

 

No state−transition constructs

 

X

X

 
 
 

example

93 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Speci cation

    Design quality experiment   Design attribute Designed from English Designed from SpecCharts
 
 
 

Design quality experiment

 

Design attribute

Designed from English

Designed from SpecCharts

Control transistors

3130

2630

 

Datapath transistors

2277

2251

Total transistors

5407

4881

Total pins

38

38

No loss in design quality with an executable language

 
 
 
 

example

94 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Speci cation

Summary Executable languages encourage precision and automation The language should support an appropriate model Makes
Summary
Executable languages encourage precision and automation
The language should support an appropriate model
Makes speci cation
easy
Strongly parallels programming languages
Structured vs. assembly languages
Object-oriented model and C++
Speci cation
example
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
95 of 214
UC Irvine
Translation Model often unsupported by a standard language (1) Use a standard language anyway Many
Translation
Model often unsupported by a standard language
(1) Use a standard language anyway
Many tools available
But, captures model unnaturally
(2) Use an application-speci c language
Captures model naturally
But, not many tools available
(3) Use a front-end language
Captures model naturally
Many tools available after translating to a standard
96 of 214
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
UC Irvine
    Outline Front-end language in VHDL environment State machine translation Fork-join translation
 
 
 

Outline

Front-end language in VHDL environment

State machine translation

Fork-join translation

Exception translation

 
 

97 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Translation

A front-end language in a VHDL environment VHDL SpecCharts Translator VHDL VHDL environment Synthesis tool
A front-end language in a VHDL environment
VHDL
SpecCharts
Translator
VHDL
VHDL environment
Synthesis
tool
Simulator
Debuger
Test−generator
Tool output
Translation
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
98 of 214
UC Irvine
State machine translation type state_type is (P, Q, R); variable state : state_type := P;

State machine translation

State machine translation type state_type is (P, Q, R); variable state : state_type := P; loop

type state_type is (P, Q, R); variable state : state_type := P;

loop case (state) is when P => <actions for P> if (u) then state := Q; else if (not u) then state := R; end if; when Q => <actions for Q> state := P; when R => <actions for R> state := Q; end case; end loop;

start

u not u P Q R
u
not u
P
Q
R

(a)

(b)

:= Q; end case; end loop; start u not u P Q R (a) (b) UC

UC Irvine

Translation

99 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

    Fork-join translation signal fork, P1_done, P2_done : boolean;   Main: process begin Main
 
 
 

Fork-join translation

signal fork, P1_done, P2_done : boolean;

 

Main: process begin

Main : process begin

P1_process : process begin

statement1;

statement1;

wait until fork;

parallel

P1;

{

fork <= true; wait until P1_done and P2_done;

P1;

P1_done <= true; wait until not fork; P1_done <= false;

 

P2;

}

statement2;

statement2;

end;

(a)

(b)

 
 
 

100 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Translation

    Exception translation   event e : T −−> S; −− T T_loop :
 
 
 

Exception translation

 

event e :

T −−> S;

−− T T_loop : loop statement; if (e) exit T_loop;

 
 

−− T

statement1;

T

: statement1;

statement2;

statement3;

 

if (e) goto S_start;

statement2;

statement2;

if (e) exit T_loop;

 

if (e) goto S_start;

statement3;

statement3;

exit T_loop; end loop;

S

: statement4;

S_start:

−− S

−− S

statement4;

statement4;

statement5;

statement5;

statement5;

 

(a)

(b)

(c)

 
 
 

101 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Translation

    Summary The perfect standard language may never exist No standard language supports all
 
 
 

Summary

The perfect standard language may never exist

No standard language supports all models

Using a front-end language solves the problem

Natural captureall models Using a front-end language solves the problem Large base of tools and expertise Translators

Large base of tools and expertisea front-end language solves the problem Natural capture Translators are simple Maps characteristics to existing

Translators are simple

Maps characteristics to existing constructsLarge base of tools and expertise Translators are simple Generates well-structured and consistent output  

Generates well-structured and consistent outputare simple Maps characteristics to existing constructs     102 of 214 Copyright (c) 1994 Daniel

 
 
 

102 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

Translation

System partitioning System functionality is implemented on system components ASICs, processors, memories, buses Two
System partitioning
System functionality is implemented on system components
ASICs, processors, memories, buses
Two design tasks:
Allocate system components or ASIC constraints
Partition functionality among components
Constraints
Cost, performance, size, power
Partitioning is a central system design task
103 of 214
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
UC Irvine
    Outline Structural vs. functional partitioning   Natural vs. executable language speci cations
 
 
 

Outline

Structural vs. functional partitioning

 

Natural vs. executable language speci cations

 

Basic partitioning issues and algorithms

 

Functional partitioning techniques for hardware

 

Hardware/software partitioning

 

Functional partitioning techniques for software

 

Exploring tradeoffs with functional partitioning

 
 
 

104 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

System partitioning

  Structural vs. functional partitioning Structural: Implement structure, then partition Functional:
 
 

Structural vs. functional partitioning

Structural: Implement structure, then partition

Functional: Partition function, then implement

Enables better size/performance tradeoffspartition Functional: Partition function, then implement Uses fewer objects, better for algorithms/humans Permits

Uses fewer objects, better for algorithms/humansthen implement Enables better size/performance tradeoffs Permits hardware/software solutions But, it’s harder than

Permits hardware/software solutionstradeoffs Uses fewer objects, better for algorithms/humans But, it’s harder than graph partitioning     105

But, it’s harder than graph partitioningfor algorithms/humans Permits hardware/software solutions     105 of 214 Copyright (c) 1994 Daniel D.

 
 
 

105 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

System partitioning

Natural vs. executable language speci cations Alternative methods for specifying functionality Natural languages common
Natural vs. executable language speci cations
Alternative methods for specifying functionality
Natural languages common in practice
Executable languages becoming popular
Automated estimation/partitioning explores solutions
Early veri cation
reduces costly late changes
Precision eases integration
System partitioning
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
106 of 214
UC Irvine
  Basic partitioning issues   Specification abstraction−level Granularity Metrics and estimations
 
 

Basic partitioning issues

 

Specification abstraction−level

Granularity

Granularity

Metrics and estimations Partitioning algorithms Objective and closeness functions

System−component allocation

Output

 
 

107 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

System partitioning

Basic partitioning issues (cont.) Speci cation-abstraction level: input de nition Just indicating the language is
Basic partitioning issues (cont.)
Speci cation-abstraction level: input de nition
Just indicating the language is insuf cient
Abstraction-level indicates amount of design already done
e.g. task DFG, tasks, CDFG, FSMD
Granularity: speci cation
size in each object
Fine granularity yields more possible designs
Coarse granularity better for computation, designer interaction
e.g. tasks, procedures, statement blocks, statements
Component allocation: types and numbers
e.g. ASICs, processors, memories, buses
Output: format and uses
e.g. new speci cation, hints to synthesis tool
System partitioning
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
108 of 214
UC Irvine
    Basic partitioning issues (cont.)   Metrics and estimations: "good" partition attributes
 
 
 

Basic partitioning issues (cont.)

 

Metrics and estimations: "good" partition attributes

e.g. cost, speed, power, size, pins, testability, reliabilityMetrics and estimations: "good" partition attributes Estimates derived from quick, rough implementation Speed and

Estimates derived from quick, rough implementationcost, speed, power, size, pins, testability, reliability Speed and accuracy are competing goals of estimation

Speed and accuracy are competing goals of estimationEstimates derived from quick, rough implementation Objective and closeness functions   Combines

Objective and closeness functions

 

Combines multiple metric values 

 

Closeness used for grouping before complete partition 

 

Weighted sum common 

 

e.g.1 2 3

1

2

3

 
 
 

109 of 214

 

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

System partitioning

Basic partitioning issues (cont.) A Algorithms: control strategies seeking best partition B Cost Constructive
Basic partitioning issues (cont.)
A
Algorithms: control strategies
seeking best partition
B
Cost
Constructive creates partition
Iterative improves partition
Number of moves
Key is to escape local minimum
System partitioning
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
110 of 214
UC Irvine
Typical partitioning-system con guration User interface Input Output Model Algorithms Estimators Design feedback
Typical partitioning-system con guration
User interface
Input
Output
Model
Algorithms
Estimators
Design
feedback
Objective
function
System partitioning
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
111 of 214
UC Irvine
    Basic partitioning algorithms   Clustering and multi-stage clustering [Joh67, LT91] Group
 
 
 

Basic partitioning algorithms

 

Clustering and multi-stage clustering [Joh67, LT91]

Group migration (a.k.a. min-cut or Kernighan/Lin) [KL70, FM82]

 

Ratio cut [KC91]

Simulated annealing [KGV83]

 

Genetic evolution

Integer linear programming

 
 
 
 

112 of 214

Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong

UC Irvine

 

System partitioning

Hierarchical clustering Constructive algorithm using closeness metrics Overview Groups closest objects Recomputes
Hierarchical clustering
Constructive algorithm using closeness metrics
Overview
Groups closest objects
Recomputes closenesses
Repeats until termination condition met
Cluster tree maintains history of merges
Cutline across the tree de nes
a partition
System partitioning
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
113 of 214
UC Irvine
Hierarchical clustering algorithm /* Initialize each object as a group */ for each loop end
Hierarchical clustering algorithm
/* Initialize each object as a group */
for each
loop
end loop
/* Compute closenesses between objects */
for each
loop
for each
loop
ComputeCloseness(
)
end loop
end loop
/* Merge closest objects and recompute closenesses
*/
while not Terminate(
) loop
FindClosestObjects(
)
for each
loop
ComputeCloseness(
)
end loop
end loop
return
System partitioning
Copyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong
114 of 214
UC Irvine
    Hierarchical clustering example   o 1 30 25 10 15 o o 2
 
 
 

Hierarchical clustering example

 
o 1 30 25 10 15 o o 2 3
o
1
30
25
10
15
o
o
2
3

10

o

4

10

10 o 4 Avg(10,10) = 10 Avg(15,25) = 20
10
o
4
Avg(10,10) = 10
Avg(15,25) = 20

o

2

o

10

1

20

o

3

 
o 1
o
1
 
o 1 o o 2 3
o
1
o
o
2
3

o

4

 
o 2
o
2
 
o 3
o
3
 
10 o 4
10
o
4
 
       
       
       
       
       
     
       
       
 

o

1

o

2

o

3

o

4

o

1

o

2

o

3

o

4

o

1

o

2

o

3

o

4

o

1

o

2

o

3