Synchronous Reactive Communication: Generalization, Implementation, and

Optimization

Guoqiang Gerald WangPhD Candidate

Committee in charge:Prof. Alberto Sangiovanni-Vincentelli, Chair

Prof. Robert K. BraytonProf. Zuojun ShenDecember 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

• 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

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

firingsBackground4

• 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

designBackground

6

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 ratetime

0 2 8 16

0 2 8 16

time

time

Task 1

Task 2

-> 6.1

Background

unschedulable

8

Options Pros ConsSingle task Easy to

constructPoor resource

utilizationMultiple task

Better scheduling

Tricky due to preemption

Block 1 Block 2Period/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

Donald, I am sending $5

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 > prioritydperiodm < periodd

Get $1 and a banana.

t0 t1Communication is not atomic

t2 t3 t4 t5

Background9

Model Implementation (Case II)

$5

My turn to run. But need

to wait.

Time for me to run

Donald, I am sending $5

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 DifferenceSR Semantics

$5

Case I

$1

Case IIdata

integrity problem

data determinism

problem

simulation time

real time

real time

$5

$5

$5

$1

$5

$1

first

second

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 • 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 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

Mapping

Export

Methodology15

Design FlowSpecification of SR models

Executable fileMethodology

System Generator(SG)

Application configuration files

(OIL)

OSEK COM

OSEK OSKernelFiles 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

idiR

if j ia j is jiC

idiR

iC

i

iT

17

Outline • 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 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

R 1T

M 2M1M

1

w

w

R 1T

• 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[]

curprev

NB NLPR 1 1= + +

01

2

3

4

5

6

0

1

2

3

4

5

2

50

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 kwi wO T

i

1 i NR w

lNB max T

n 1n

buffer indexwriter instance

nk

n 1k 1

nn 1wT

id

wiO iR

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

n 1

activatedI 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 • 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 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

BCC1Multiple active task instance

no

Tasks not in suspended state

8

> 1 task per priority noEvent 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

OSEK Implementation28

• Application task

Implementation (cont)

CTDBP TCCPTASK (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(); }

OSEK Implementation29

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 complexGood for Slow readers Fast readers

OSEK Implementation30

Outline • 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 31

Mathematical Formulation• Fixed given priority

– Parameters:

– Variables:

i j

i, j

1 if > p

0 otherwise

j NRj 1i i,j i,jNRS x L i i iNRF NR NRS

i j

i, j

1 if w rL

0 otherwise

i, j

CTDBPi j

TCCPi j

1 if w rx

0 if w r

j NR( j )(i)j 1i i,j i,jw ,r

NLPRS 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)wmaxTCCP: 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

NRi 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,j1 j NR w

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 xT T

R C CST

i

d,ter i,clk clk,terclk

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 Te

st C

ases

14% 24%

4.8%

Optimization35

Outline • 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 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 softwareCode Generation

37

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 ResultsRTW 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