SPECIFICATION AND DESIGN OF EMBEDDED SYSTEMSpahsiung/courses/codesign/notes/3_Models... · Models &...

UC IrvineCopyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie Gong1 of 214

SPECIFICATION AND DESIGNOF

EMBEDDED SYSTEMS

by

Daniel D. GajskiFrank Vahid

Sanjiv NarayanJie Gong

University of California at IrvineDepartment of Computer Science

Irvine, CA 92715-3425

UC IrvineCopyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie GongIntroduction 2 of 214

Design representation s

� BehavioralRepresents functionality but not implementation

� StructuralRepresents connectivity but not dimensionality

� PhysicalRepresents dimensionality but not functionality


Levels of abstraction

Transistor

Gate

Register

Processor

Behavioral forms

Structuralcomponents

Physical objects

Levels

PCBs,MCMs

Differential eq.,current−voltage diagrams

Boolean equations,finite−state machines

Executable spec., programs

Processors, controllers, memories, ASICs

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

Gates,flip−flops

Transistors, resistors, capacitors

Analog and digital cells

Modules, units

Microchips, ASICs

Algorithms, flowcharts, instruction sets,generalized FSM


Design methodologies

� Capture-and-simulateSchematic captureSimulation

� Describe-and-synthesizeHardware description languageBehavioral synthesisLogic synthesis

� Specify-explore-refineExecutable specificationSoftware and hardware partitioningEstimation and explorationSpecification refinement


Motivation

if (x = 0) then y = a * b / 2

Processor Memory

ASIC I/O

Executablespecification

Systemimplementation

Models

Languages

Partitioning

Estimation

Refinement

Videoaccelerator

Behavioral synthesisLogic synthesis

Software compilation Physical designTest generationManufacturing

UC IrvineCopyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie GongOutline 6 of 214

Outline

� Introduction

� Design models and architectures

� System-design languages

� An example

� Translation

� Partitioning

� Estimation

� Refinement

� Methodology and environments

UC IrvineCopyright (c) 1994 Daniel D. Gajski, Frank Vahid, Sanjiv Narayan, and Jie GongModels & Architectures 7 of 214

Models and architectures

Implementation

Designprocess

Models are conceptual views of the system’s functionality

Models

Architectures

Specification + Constraints

Architectures are abstract views of the system’s implementation

(Specification)

(Implementation)


Models and architectures

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

� Architecture: a set of implementation components and their connections


Models of an elevator controller

then the elevator remains idle.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;

then lower the elevator to the requested floor.

"If the elevator is stationary and the floor requested is equal to the current floor,

If the elevator is stationary and the floor requested is less than the current floor,

If the elevator is stationary and the floor requested is greater than the current floor, then raise the elevator to the requested floor."

(req_floor < curr_floor)/ direction := down

�

(req_floor = curr_floor)/ direction := idle

�(req_floor > curr_floor)

/ direction := up

�(req_floor = curr_floor)

/ direction := idle

� (req_floor = curr_floor)/ direction := idle

�(req_floor > curr_floor)

/ direction := up

�(req_floor < curr_floor)/ direction := down

�

(req_floor < curr_floor)

/ direction := down

�

(req_floor < curr_floor)

/ direction := up

�UpIdleDown

(a) English description (b) Algorithmic model

(c) State−machine model


Architectures for implementing the elevator controller

State register

directionC

ombi

natio

nal l

ogicreq_floor

curr_floor

In/out ports

MemoryProcessorBus

req_floorcurr_floor direction

(b) System level(a) Register level


Models

� State-oriented modelsFinite-state machine (FSM), Petri net, Hierarchical concurrent FSM

� Activity-oriented modelsData flowgraph, Flowchart

� Structure-oriented modelsBlock diagram, RT netlist, Gate netlist

� Data-oriented modelsEntity-relationship diagram, Jackson’s diagram

� Heterogeneous modelsControl/data flowgraph, Structure chart, Programming language paradigm,Object-oriented paradigm, Program-state machine, Queueing model


State oriented: Finite-state machine (Mealy model)

S1S2

S3

startr2/u1

r1/d1

r3/u2r1/d2r2

/d1

r3/u

1

r2/n

r3/n

r1/n

S = { s1, s2, s3}I = {r1, r2, r3}O = {d2, d1, n, u1, u2}f: S x I −> Sh: S x I −> O


State oriented: Finite-state machine (Moore model)

S12

S

S11

13

S

S

21

S22

23

S

S

S

31

33

32

start/d2

�

/d1

�

/n

�

/d1

�/n

�/u1

�

/n

�/u1

�

/u2

�r1r1r1

r2

r1

r1

r1

r2

r2

r1

r1

r1r2

r2

r3

r3r2

r2

r3

r3

r3r2r3r2

r3r3r3


State oriented: Finite-state machine with datapath

S1

(curr_floor != req_floor) / output := req_floor − curr_floor; curr_floor := req_floor

�(curr_floor = req_floor) / output := 0

�start


Finite-state machines

� Merits:represent system’s temporal behavior explicitlysuitable for control-dominated system

� Demerits:lack of hierarchy and concurrency resulting instate or arc explosion when representing complex systems


State oriented: Petri nets

Net = (P, T, I, O, u)P = {p1, p2, p3, p4, p5}T = {t1, t2, t3, t4}

I(t1) = {p1}I(t2) = {p2,p3,p5}I(t3) = {p3}I(t4) = {p4}

p1 p5

p2

p3

p4t4

t3

t2t1

I: O: u: u(p1) = 1u(p2) = 1u(p3) = 2u(p4) = 0u(p5) = 1

O(t1) = {p5}O(t2) = {p3,p5}O(t3) = {p4}O(t4) = {p2,p3}


Petri nets

t2 t1 t1t2t1

t1 t2 t1 t2 t3 t4

(a) Sequence (b) Branch (c) Synchronization

(d) Resource contention (e) Concurrency


Petri nets

� Merits:good at modeling and analyzing concurrent systems

� Demerits:‘flat’ model that isincomprehensible when system complexity increases


State oriented: Hierarchical concurrent FSM

Y

A

B

C

D

E

F

G

b

u

r

as

a(P)/c


Hierarchical concurrent FSMs

� Merits:support both hierarchy and concurrencygood for representing complex systems

� Demerits:concentrate only on modeling control aspectsand not data and activities


Activit y oriented : Data flowgraphs (DFG)

A 1 A 2

X

Y

V V’

Z

W

Y

W

Z

V’

A 2.1 A 2.2

A 2.3

File

+

X

Y W*

Z

Input

Output

Output

(a) Activity level (b) Operation level


Data flowgraphs

� Merits:support hierarchysuitable for specifying complex transformational systemsrepresent problem-inherent data dependencies

� Demerits:do not express temporal behaviors or control sequencingweak for modeling embedded systems


Activity oriented: Flowchart (CFG)

MAX = MEM(J)

J = 1MAX = 0

J = J+1

J > N MEM(J) > MAX

start

No

Yes

Yes

No

end


Flowcharts

� Merits:useful to represent tasks governed by control flowcan impose an order to supersede natural data dependencies

� Characteristics:used only when the system’s computation is well known


Structure oriented: Component-conn ectivit y diagrams

Register file

ALU

LIR RIR

Rightbus

Leftbus

A B

Processor

Programmemory

Datamemory

I/Ocoprocessor

Application specific hardware

System bus

(a) Block diagram (b) RT netlist (c) Gate netlist


Component-con nectiv ity diagrams

� Merits:good at representing system’s structure

� Characteristics:often used in the later phases of design process


Data oriented: Entity-relationshi p diagram

OrderCustomer

ProductSupplier

Availability

P.O.instance

Request


Entity-relationship diagrams

� Merits:provide a good view of the data in the system, alsosuitable for expressing complex relations among various kinds of data

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


Data oriented: Jackson’ s diagram

Rectangle

Drawing

Color

Circle

Width Height

Name

*

AND

OR

AND

Shape

Radius

Users


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.


Heterogeneous: Control/data flowgraph

Control

A2

A3

A1

enable

0S

1S

2S

start

disableenable

disable

disableenable

, enable / disable

�

A1 A3

/ enable

�

enable ,A1 A2

/ dis

able

�

stop

disa

ble

,A

2A

3

start stop

W = 10

X

W

Y

Z

W = 10

(a) Activity level (b) Operation level

+

1 2 E

+

+

+

Read X Read W

Write A

Const 3 Read X

Write A

Read X Const 2

Const 5

Write X Write A

A := X + WA := X + 3X := X + 2A := X + 5

Data flow graphs

Control flow graph

C


Control/data flowgraphs

� Merits:correct the inability of DFG in representing the control of a systemcorrect the inability of CFG to represent data dependencies


Heterogeneous: Structure chart

Get Transform

Get_A Get_B Change_A Change_B Do_Loop1 Do_Loop2

Compute

Main

Out_C

Datacontrol

A B

A,B

A,BA’,B’

A

A’ B’

B

A’,B’C,D

C

Branch

Iteration


Structure charts

� Merits:represent both data and control

� Characteristics:used in the preliminary stages of program design


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.


Programming languages

� Merits:model data, activity, and control

� Demerits:do not explicitly model the system’s states


Heterogeneous: Object-oriented paradigm

Data

Operations

Object

Data

Operations

Object

Data

Operations

Object

Transformation function


Object-oriented paradigms

� Merits:support information hiding, inheritance, natural concurrency

� Demerits:not suitable for systems with complicated transformation functions


Heterogeneous: Program-state machine

e2

e3

Y

A

B

C

D

e1

variable A: array[1..20] of integer

variable i, max: integer ;

max = 0;for i = 1 to 20 do if ( A[i] > max ) then max = A[i] ; end if;end for


Program-state machines

� Merits:represent system’s states, data, control and activities in a single modelovercome the limitations of programming languages and HCFSM models


Heterogeneous: Queueing model

Queue ServerArrivingrequests

Arrivingrequests

(a) One server

(b) Multiple servers


Queueing model

� Characteristics:used for analyzing system’s performance, andcan find utilization, queueing length, throughput


Architectures

� Application-specific architecturesController architecture,Datapath architecture,Finite-state machine with datapath (FSMD).

� General-purpose processorsComplex instruction set computer (CISC)Reduced instruction set computer (RISC)Vector machineVery long instruction word computer (VLIW)

� Parallel processors


Controller architecture

Next−statefunction

Outputfunction

Outputs

Inputs

State register


Datapath architecture

x(i) b(0) x(i−1) b(1) x(i−2) b(2) b(3)x(i−3)

y(i)

+ +

x(i) b(0) x(i−1) b(1) x(i−2) b(2) b(3)x(i−3)

y(i)

Pipeline stages

Pipeline stages

+

*

+

+ +

** **

* * *

(a) Three stage pipeline

(b) Four stage pipeline


FSMD

Next−statefunction

Outputfunction

Datapath

Status

Datapath inputs

Datapath outputs

Control unit

State register

Control


CISC architecture

Status

Control unit Instruction reg.

Datapath

Memory

+1

Microprogram memory

Addressselection logic

PC

MicroPC

Control


RISC architecture

Status

Control unit

Instruction reg.

Hardwiredoutput andnext−state logic

Memory

Registerfile

ALU

Instr.cache

Datacache

Datapath

State register

Control


Vector machines

Interleaved memory

Vectorregisters

Scalarregisters

Memory pipes

Memory pipes

Vectorfunctional unit

Scalarfunctional unit


VLIW architecture

+

Memory

+ * *

Register file


Parallel processors: SIMD/MIMD

Control unit

Proc. 0

Mem. 0

Proc. 1

Mem. 1

Proc. N−1

Mem. N−1

Interconnection network

PE0 PE PE1 N−1

(a) Message passing

Proc. 0

Mem. 0

Proc. 1

Mem. 1

Proc. N−1

Mem. N−1

Interconnection network

(b) Shared memory


Conclusion

� 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

Date post:	31-Oct-2019
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

SPECIFICATION AND DESIGN OF EMBEDDED SYSTEMSpahsiung/courses/codesign/notes/3_Models... · Models &...

Documents