synchronous reactive communication: generalization, implementation, and optimization guoqiang gerald...
Post on 19-Dec-2015
225 views
TRANSCRIPT
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
• 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
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
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 > 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
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 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
• 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
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
• 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
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
• 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
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
OSEK Implementation28
• 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(); }
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 complex
Good 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 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
• 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 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