Synchronous Reactive Communication: Generalization, Implementation, and Optimization Guoqiang Gerald Wang PhD Candidate Committee in charge: Prof. Alberto

Synchronous Reactive Communication: Generalization, Implementation, and

Optimization

Guoqiang Gerald WangPhD Candidate

Committee in charge:

Prof. Alberto Sangiovanni-Vincentelli, ChairProf. Robert K. Brayton

Prof. Zuojun Shen

December 9, 2008

• Background and previous work• Methodology and implementation

framework• SR semantics preserving communication

protocols• Protocol implementation under OSEK OS

standard• Memory optimization under timing

constraints• Automatic code generation• Conclusions





constraints• Automatic code generation• Conclusions

Outline

2

System-Level Design

• On the edge of a revolution in the way electronic products are designed– Increasing design complexity– High product quality– Stronger market pressure

• System-level design is the key to success– Start with the highest possible level of

abstraction (e.g. control algorithm)– Establish properties at the right level– Use formal models– Leverage multiple scientific disciplines

Background3

Models of Computation• Process Networks (PN)

– Undecidable: deadlocks and buffer boundedness• Synchronous Reactive (SR)

– WRT model time• computation doesn’t take time• All actors execute simultaneously and instantaneously

– Has strong formal properties: decidable termination & boundedness

– Good for specifying periodic real-time tasks• Discrete Event (DE)

– Signals are time-stamped events– Events are processed in chronological order– Good for modeling and design of time-based systems

• Dataflow process networks– Dataflow processes are Kahn processes composed of atomic

firingsBackground

4

• Academia:– MetroPolis (ASV, UCB)

• Meta model• Communication refinement

– Ptolemy (E. Lee, UCB) • Started with static dataflow for DSP• Mixed model verification

• Industry:– LabVIEW

• Statically schedulable dataflow (Synchronous dataflow)– Simulink

• Synchronous reactive

Implementation Tools

Background

Support multiple models of computation

5

Model-Based Design

• An instance of system-level design• Very popular

– Tool support• Design time simulation/verification

– Short development cycle– Predictable performance– Flexibility of new design evaluation– Design reuse

• The rest of the presentation– Synchronous reactive model-based

design

Background6

SR Semantics

$5

My turn to run!Time for

me to run

Donald, I am sending $5

and an apple.

Get $5 and an apple.Thanks, Mickey!

I finished.

Now I am done.

During simulation, writer and reader respond instantaneously (computation takes zero time)

Simulation time

prioritym > priorityd

periodm < periodd

t0 t1

Background7

Implementation Options of Multi-Rate systems• Single-task option

• Multiple-task option

0 2 8 16

base rate

time

0 2 8 16

0 2 8 16

time

time

Task 1

Task 2

-> 6.1

Background

unschedulable

8

Options Pros Cons

Single task Easy to construct

Poor resource utilization

Multiple task

Better scheduling

Tricky due to preemption

Block 1 Block 2

Period/Deadline (unit)

8 16

Exe time (unit) 2 6

Model Implementation (Case I)

$5

My turn to run. But need

to wait.

Time for me to run


and an apple.I finished.

Now I amdone.

Now, I can start.

I need to yield to Mickey.

Time for meto run again.

Donald, I send$1 and a banana

this time.Now I

am done.

$1

I can resume.

Start receiving.

real time

Uni-processor and priority-based preemptive scheduling

prioritym > priorityd

periodm < periodd

Get $1 and a banana.

t0 t1

Communication is not atomict2 t3 t4 t5

Background9

Model Implementation (Case II)

$5

My turn to run. But need

to wait.

Time for me to run


and an apple.I finished.

Now I amdone.

Now, I can start.Time for me

to run again.

Donald, I send$1 and a banana

this time.Now I

am done.

$1

real time

Start receiving. Got $5!

Not finished yet. Have to yield.

Resume receiving.A banana. Wow,

$5 and a banana!!

t0 t1 t2 t3 t4 t5

Background10

What Is the Difference

SR Semantics

$5

Case I

$1

Case II

data integrity

problem

data determinism

problem

simulation time

real time

real time

$5

$5

$5

$1

$5

$1

first

seco

nd

Background11

Current Approach Limitations and Solutions• Rate transition buffering scheme from The MathWorks

Background

• Furthermore, – Generalization with support of arbitrary link delay and

multiple activations per task– Memory optimization through automatic protocol

selection

• Limitations– One to one

communication• Double buffering scheme• No memory optimization

– For periodic communicating tasks:• Periods must be harmonic• Tasks must be activated

with the same phase

• Solutions– One to many

communication• Dynamic buffering and

temporal currency control protocols

– For periodic communicating tasks:• Raise the implementation up

to the kernel level

12

Outline





constraints • Automatic code generation• Conclusions 13

Methodology

• Platform-based design– Automatic generation of

• application tasks• communication protocol implementation

– Automatic configuration of RTOS procedures and data structures

– Flexibility of choice of RTOS API standard

Methodology14

Application Functional

ModelTask Model;

Communication Resource Model

Execution Architecture

Scheduling Policy: FP, DP; Communication

Resource Management Policy

RTOS API

Meet-in-the-Middle Approach• Application domain

– Time-critical applications– Modeled as SR tasks

• Platform– Task/resource model platform

• Task’s characteristics and interaction– RTOS platform

• Priority-based scheduling policies • Inter-task comm. protocols

– lock-based, lock-free, wait-free• Middle meeting point

– RTOS API• OSEK/VDX, POSIX, μITRON

• Execution architecture– Uni-processor– Priority-based preemptive

scheduling

Map

pin

gExp

ort

Methodology15

Design FlowSpecification of SR models

Executable fileMethodology

System Generator(SG)

Application configuration files

(OIL)

OSEK COM

OSEK OSKernel

Files produced by SG

User’ssourcecode

compiler

linker

Model-based design tool

Object libraries

C code

C codeC code

16

Task Model τi• Parameter characterization

– Priority:– Period:– Activation time:– Start time:– Worst-case computation time: – Finish time:– Worst-case response time:– Relative deadline:

τiNIP ··· NOP···

if j

ia j

is j

Methodology

time

id

iR

if j ia j is jiC

id

iR

iC

i

iT

17

Outline





constraints• Automatic Code Generation• Conclusions 18

SR Semantics with Link Delay

w iif delay i 0, k a j

i it supremum m| a m t

time

time

ri

w

j

w ia j

delay i

ir win j out k

ia jin

out

delay i

w ia j 1 w ia j delay[i]

···

w iif delay i 1, k max 0, a j 1

w if or any delay i , k max 0, a j delay i

SR Protocols19

w

w

R1

T

M 2M1M

1

w

w

R1

T

• General case: and• Special case: and

One to Many Communication: Single-Writer Multiple-Reader

max p,q

w

1M qM

···

···

···M

0N 1N pN ···N

q ( 1)

0 1

p

HPR:

LPR:

Link delay: design parameter

2

SR Protocols

1d T

d R T any

20

SR Semantics Preserving Communication mechanisms• Wait-free scheme• Buffer sizing mechanisms

– Spatially-out-of-order writes– Spatially-in-order writes

• Buffer indexing protocols– Dynamic Buffering Protocol (DBP)– Temporal Concurrency Control Protocol

(TCCP)

SR Protocols21

Spatially-out-of-Order Writes

• Buffer sizing:

LPR

HPR

Buf[] Read[]

cur

prev

NB NLPR 1 1= + +

0

1

2

3

4

5

6

0

1

2

3

4

5

2

5

0

0

3

4

2

2

2

5

1 1

SR Protocols22

Spatially-in-Order Writes

• Offset

• Buffer sizing

wi i wo a k a j w ij sup m| a m a k

wi wO T

i

1 i NRw

lNB max

T

n 1n

buffer indexwriter instance

nk

n 1k 1

nn 1

wT

id

wiO iR

i w wi ilif etime l delay[i] T O R

n 1

activated

I finished.

Unitdelay

SR Protocols23

How to Guarantee SR Semantics • Handle communication at two levels

– Buffer indices defined at activation time by kernel

– Data reading/writing at execution time by application tasks

SR Protocols24

The ProtocolsConstant Time Dynamic Buffer Protocol (CTDBP)

Reader i Writer/* activation time */if (delay[i]) Read[i] = prev;else Read[i] = cur;if (isHPR[i] == 0) UseFreeL[Read[i]]++;

/* execution time */······ = Buf[Read[i]];···/* termination time (CS)*/if (isHPR[i] == 0) UseDec(Read[i]);

/* activation time */UseDec(prev);prev = cur;cur = FindFreeC();UseFreeL[cur] = 1; /* execution time */···Buf[cur] = ······

Def of UseDec()void UseDec(int j) { UseFreeL[j]--; if (UseFreeL[j] == 0) { UseFreeL[j] = FreeHd; FreeHd = j; }}

Def of FindFreeC()char FindFreeC(void) { tmp = FreeHd; FreeHd = UseFreeL[tmp]; return tmp;} /* O(1) */

Temporal Concurrency Control Protocol (TCCP)Reader i Writer i/* activation time */if (delay[i]) Read[i] = prev;else Read[i] = cur;

/* execution time */······ = Buf[Read[i]];···

/* activation time */prev = cur;cur = FindFreeT(); /* execution time */···Buf[cur] = ······Def of FindFreeT()char FindFreeT(void) { return (cur+1) % NB;} /* O(1) */

SR Protocols

2FreeHd 34115-1

UseFreeL[6]

012345

25

Outline





constraints• Automatic code generation• Conclusions 26

OSEK/VDX

• A series of standards particularly for automotive designs

• Basic and extended tasks• Four Conformance Classes

– BCC1, BCC2, ECC1, ECC2• Portability

– Minimum requirement of CC• Kernel services:

– Task management, alarm, hook mechanism• OIL

– Modular configuration for system generation

BCC1

Multiple active task instance

no

Tasks not in suspended state

8

> 1 task per priority no

Event per task -

Alarm 1

OSEK Implementation27

An OSEK/VDX Implementation

• Portable implementation– BCC1– Minimum Requirement

• Only one alarm

• Task dispatcher– GCD of rates

TickL[LCMR] DispT[TSize]

tick sizeDispHd

Ck,d,1

1 TASK (dispatcher) { 2 tick = (tick+1) % LCMR; 3 if (TickL[tick].DispHd != -1) { 4 for (k = 0; k < TickL[tick].size; k++) { 5 idx = DispT[k+TickL[tick].DispHd]; 6 for (i = 0; k < TaskL[idx].NOP; i++) { 7 idx2 = TaskL[idx].OPHd + i; 8 …/* kernel level writer code */ 9 }10 }11 for (k = 0; k < TickL[tick].size; k++) { 12 idx = DispT[k+TickL[tick].DispHd]; 13 for (i = 0; k < TaskL[idx].NIP; i++) {14 idx2 = TaskL[idx].IPHd + i;15 …/* kernel level reader code */16 }17 ActivateTask(idx);18 }19 }20 TerminateTask();21 }

Ck,d,2

Ck,τ,1

Ck,w

Ck,τ,2

Ck,r

Ck,τ,3

Ck,d,3


• Application task

Implementation (cont)

CTDBP TCCP

TASK (AppTask_i) { TaskL[i].done = false; ··· /* each writer w */ Buf[OPL[w].cur] = ··· ··· /* each reader r */ ··· = Buf[Read[r]]; ··· TaskL[i].done = true; /* hook routine */ TerminateTask();}

void PostTaskHook(void) { int id, j, k, nip; GetTaskID(id); if (TaskL[id].done) { nip = TaskL[id].NIP; for (j=0; j<nip; j++) { k = j + TaskL[id].IPHd; /* atomic termination code */ } }}

TASK (AppTask_i) { ··· /* each writer w */ Buf[OPL[w].cur] = ··· ··· /* each reader r */ ··· = Buf[Read[r]]; ··· TerminateTask(); }


Comparison of CTDBP & TCCP

Protocol CTDBP TCCP

# of buffers SysNBD SysNBT

Sizing mechanism

Dedicated buffers for readers

How many times writer can write

Difficulty of sizing

Easy Difficult

Temporal property

Fast Faster

Data structures Complex Less complex

Good for Slow readers Fast readers


Outline





constraints• Automatic code generation• Conclusions 31

Mathematical Formulation

• Fixed given priority

– Parameters:

– Variables:

i j

i, j

1 if > p

0 otherwise

j NR

j 1i i,j i,jNRS x L

i i iNRF NR NRS

i j

i, j

1 if w rL

0 otherwise

i, j

CTDBP

i j

TCCP

i j

1 if w rx

0 if w r

j NR

( j )(i)j 1i i,j i,jw ,rNLPRS x p L

i, j i, j i

i

i i j NRmax delay[j ]LNLPRS 1 x if NRS > 0

CTDBP: NBS0 otherwise

lj

i i,j i,jT1 j NR (i)w

maxTCCP: NBF (1 x ) L

Buffer sizing mechanisms:

Optimization32

Partial cost of dispatcher

NR NR

i i,j i,j i i i,j i,jj 1 j 11 i NW, min 1, x L , min 1,NR x L

NW NW

i ii 1 i 1min 1, , min 1,

Complete Formulation

i is.t. 1 i NT, R d

NW

i ii 1minimize NB NBF NBS

( j )(i)

1 j NR

NR

i i,j i,j i,j i,j ij 1 w ,r1 i NW, NBS x p L 1 max delay j x L

(i)

ji i,j i,j

1 j NRw

l1 i NW, NBF 1 x Lmax

T

j j

NTi i

i i j i,j j ,ter k,j hp i \ k j 1j j

NR NWi i

j jS j ,j S j ,jj 1 j 1r w

ik,d clk,d

d

R R1 i NT, R C C CS CS C

T T

R Rx 1 x

T T

RC CS

T

id,ter i,clk clk,ter

clk

RCS CS CS

T

(S(i)) (i) i S(i),iw r1 i NR, l delay i T O R

Reformulate: MILP

Schedulability constraint

Buffer size

Lifetime

WCRT

Protocol flag

D Tk, k, k,C C 1 C

D TCS CS 1 CS Cost of context switches

- Ck,w Ck,r

TCCP Δ Φ

CTDBP Ψ Γ

Optimization33

Experimental Setup

• Performance evaluation environment– PIC18F452

• Performance up to 10 MIPS– ePICos18

• Multi-task, preemptive, O(1) kernel scheduler• OSEK compliant

• Task graphs generated by TGFF– 809 systems (158 unschedulable)

• On average, 12 tasks/graph; execution time: 6•104ICs; task period: 106ICs

• ≤ 4(8) writers(readers)/task; ≤ 2-unit delay;

Optimization34

Experimental Results

0 (0%, 5%]

(5%, 10%]

(10%,15%]

(15%, 20%]

(20%,25%]

(25%,30%]

(30%,35%]

(35%,40%]

(40%,45%]

(45%,50%]

(50%,55%]

(55%,60%]

0

0.05

0.1

0.15

0.2

0.25

0.3

105 Systems: Smaller Buffer Size under CTDBP than TCCP

w.r.t. CTDBP w.r.t TCCP

Relative Improvement

Perc

enta

ge o

f Test

Cases

14% 24%

4.8%

Optimization35

Outline





constraints• Automatic code generation • Conclusions 36

Real-Time Workshop

• Simulink system functions (S-Functions)– Extend capability of Simulink

environment– Coded in C or MATLAB

• Target Language Compiler (TLC)– From graphical model to intermediate

form– Eventually into target specific code

• RTW Embedded Coder (E-Coder)– Framework for development of

embedded software

Code Generation37

SR Implementation Library

Code Generation38

Example of DyB

Given: sampling rates, buffer initial value (8)

Period of task dispatcher?

How many buffer slots?

How many tasks?

GCD(2,3,5) = 1

Code Generation

5

NLPR + 1 + 1 = 3

39

Simulation/Emulation Results

RTW MPLAB(PIC18F452) + ePICos18

Period = 3

Period = 5

Period = 2

Code Generation40

Conclusions

• Generalized theory on SR semantics preserving communication

• Implemented protocols with portability consideration under the OSEK OS standard

• Optimized memory and supported a wider range of applications under timing constraints with automatic protocol selection

• Supported automatic code generation for SR communication protocols

41

Thank you

42

Documents

Synchronous Reactive Communication: Generalization, Implementation, and Optimization Guoqiang Gerald Wang PhD Candidate Committee in charge: Prof. Alberto