data flow modeling of radio applicationssander/tutorials/compsoc-sdf3/...dynamic scheduler modeling:...

Data Flow Modeling of Radio Applications

Orlando Moreira Principal DSP Systems Engineer [email protected]

multi-radio devices

WLAN Base station

3G Base stationHSPA Multi-Radio

Smartphones

2G Base stationGSM

GPS Satellite

Friday, January 27, 2012

Multi-radio devices

Application: Radio PHY

radios are real-time applications: !•  modems must meet deadlines defined by the standard!•  throughput, latency requirements!

05/13/09 CONFIDENTIAL

extending data flow to meet the requirements

traditional data flow analysis cannot handle: latency requirements data dependent behavior

but this is required by radio applications.

eg: WLAN packet and timingText

Sync Hea Payload SIFS

Variable size N x 4 µs4 µs8 µs 16 µs

Deadline for sending ACK


Application: Radio PHY!

radios are streaming applications:!•  receiving/sending virtually infinite data sequences !•  iterative schedules with overlapped execution!•  inter-iteration dependencies!

background motivation variants results conclusion application: radio baseband

radios are streaming applications receiving/sending virtually infinite data sequences

radios are real-time applications: correct operation requires doing things in time modems must meet deadlines defined by the standard

RF A/D IT OT MAC


application: radio baseband

radios are streaming applications receiving/sending virtually infinite data sequences

radios are real-time applications: correct operation requires doing things in time modems must meet deadlines defined by the standard

RF A/D IT OT MAC


Hardware: Heterogeneous Multiprocessor

Multi Radio Vision: The Radio Computer!

•  multiple radios run simultaneously on multiprocessor!•  sharing cores, memory and communication!•  radios developed and installed independently!•  each radio meets hard deadlines!

what if radios could share hardware?

the radio computer vision: a radio is software running on the radio computer; user installs and runs radios just like apps on a PC; multiple radios run simultaneously in shared hardware; radios are developed in isolation, delivered independently.

5

Radio Computer Operating System

Radio 1 Radio 2 Radio 3

RF A/D IT OT MAC


SDR Vision: Software Architecture

•  provide power-efficient, real-time schedules!

•  support wide variety of radio combinations and transitions!•  allow post-design updates and add-ons!

•  simplify the radio design process !

what if radios could share hardware?

the radio computer vision: a radio is software running on the radio computer; user installs and runs radios just like apps on a PC; multiple radios run simultaneously in shared hardware; radios are developed in isolation, delivered independently.

5

Radio Computer Operating System

Radio 1 Radio 2 Radio 3

RF A/D IT OT MAC


8

Refining the requirements

real-time guarantees!•  automated analysis (no manually-derived models)!•  no scheduling anomalies, no deadlocks, no buffer overruns !ease of programming/testing/debugging:!•  correct-by-construction concurrent behavior!•  code generation for communication, synchronization!efficiency:!•  static scheduling whenever possible!•  static determination of buffer sizes!•  distributed runtime synchronization (to avoid bottlenecks)!

9

Avoiding unpredictable behavior

Platform:!!   Resource contention!!   Unbound time to service from resource…!!   … or large difference between average and worst case

provision!!   Results in: starvation, scheduling anomalies, over-allocation

,…!

Solution: Budgeted arbitration !!  schedulers with service guarantees in all share points!

10

Avoiding unpredictable behavior

Application:!!   Non-deterministic functional behavior!!   Dynamism (data-dependent behavior)!!   Results in: deadlocks, halting problem, unbounded memory

,… !

Solution: Restrict programming model !!  Domain-specific: find right trade-off expressivity vs

analyzability!

Data Flow

Src D B C Snk

E F

A

For Real-time Analysis: a composable model for analysis of temporal behavior For Software Engineering: a concurrent Component Model with strong formal properties (as opposed to UML)

Data Flow

Actors: computing stations with well-defined data-driven activation rules!Arcs: FIFO channels!Tokens: Initial data items in Arcs – imply inter-iteration dependencies (static DF)!

Src D B C Snk

E F

A

Data Flow – Static Analysis

•  Longest cycle bounds maximum rate. !•  Execution in bounded buffer space.!•  There is always a static periodic schedule that achieves maximum rate.!•  Self timed execution upper bounded by static periodic schedule.!•  Monotonic, Linear in timing: No scheduling anomalies.

Src D B C Snk

E F

A

Data flow formalism: function + mapping+ analysis

Src D B C Snk

E F

A

Src D B C Snk

E F

A N1 N2 N3 N4 N5

N6 N7

data flow unifies concurrent application specification & timing analysis of mapping

Programming Model: Specifying Functionality per RAT

Analysis Model: Modeling Mapping Decisions

Modeling of buffer sizes, static ordering, communication overhead, dynamic schedulers.

Scheduling Policy – intra vs inter graph

intra-graph

•  dependencies known

•  dependencies are static or quasi-static

•  related rates of execution between tasks

•  shared temporal requirements

inter-graph!•  no dependencies!•  independent start, stop!•  independent rates!

•  independent timing requirements!

•  contention for resources!

Src1

275000

Src2

12500

DASS

19000

JD1

27500

Src3

100000

MI

42000

CE

33000

Src4

287500

DecCRC1

25000

JD2

15500

DecCRC2

25000

TFCI

2000

TPC

1000

Latency2

285500

Latency3

395000

Latency1

285680

Src1

2400

Src2

800

Detect

220

Hdemode

920

Src3

2400

FFEnCE

680

CFEnSync

355

Src4

1600

Src5

2400

Src7

4000

Src6

4000

HDecode

920

PDemode

920

PDecode

920

MacCRC

500

MacAnalyse

1000

BuildHeader

500

CodeHeader

920

AckCodeAckMode

920

SIFS

16000

ModHeader

920

5:1

5:1

1:5

1:5

SDF model for WLAN

TDS-CDMA Receiver WLAN Receiver

Scheduling Policy – intra vs inter graph

intra-graph!inter-processor synchronization:

self-timed & data-driven!intra-processor: quasi-static order !

•  determined at compile time!•  no scheduler overhead!

inter-graph!per processor: budget scheduler!•  guarantees per reservation!•  isolates graph from interference!global resource manager!

•  reservation of resources, processor binding at graph startup !

A

C

B

D

E

WLAN

TDM Scheduler

A

C

B

D

E

TDM Scheduler

Software Architecture for SDR

Compile-Time (Budgeting) For each graph

Run-Time (Admission Control) For each graph start request

Transceiver Component

DataflowCompiler

Transceiver GraphTransceiver

Component

Architecture Description

Transceiver Budget

RelocatableExecutables

Timing Requirements

SchedulerSettingsSchedulerSettings

TDM Scheduler

Executablet

Resource Manager

TransceiverBudget

Executables

Current Resource Allocation

SchedulerSettings

TDM Scheduler

New Resource Allocation

TDM Scheduler

SchedulerSettingsSchedulerSettingsSchedulerSettings

TDM Scheduler

TDM Scheduler

Round-Robin Scheduler

LoaderOther

schedulers/arbiters

Clustering, Static ordering per cluster, Buffer sizes, Run-time scheduler settings

per cluster Admission control, actor to processor binding, load tasks, configure run-time

schedulers

Core Compiler

Transceiver Component

DataflowCompiler FETransceiver

Graph

Transceiver Component Dataflow

Transceiver

DataflowScheduler

Architecture Description

TimingAnnotation

Timing Requirements

Quasi-static clusters

Transceiver Budget

Code Generator

Core Compiler

T iming AnnotationTAnnotationAnnotationEmbedded

OS task

Core compilerCore compilerCore Compiler

RelocatableExecutables

DataflowModeling

DataflowAnalysis

(Partial)TentativeMapping

TemporalAnalysis ModelYes or No

Programming Flow in Detail

No disparity between analysis model and implementation

Dynamic Scheduler Modeling: TDM

A

TDM

Latency-rate server data flow model

P: Period of the TDM scheduler S(A): Slice allocated to A T(A) : Worst-case Execution time of A

Latency rate model [Wiggers2007]: !approximation for any starvation-free scheduler!accuracy depends on the scheduler!

AL AR

tAL=P-S(A) tAR=P.T(A)/S(A)

DF Modeling: Composition of TDM arbitrations

20

A

C

B

D AR

CL

BL

DL AL

CR

DL

BR

Latency-rate server model can be used for any starvation-free/budget schedulers. It can for some cases be rather pessimistic.

4

Data flow Modeling: Problem with the LR-Model

3 12 9 6 18 15

4 5.. 1 3 2.. ..2

1 3 2

PERIOD = 6 SLICE SIZE = 3 EXEC TIME = 2

Fig: The LR-model over-estimates the worst-case temporal behavior of TDM arbitration by a factor of (P/S)

But do not fear. A model with precise worst-case is on the way!

21

05/13/09

Modeling TDM combined with Static Order

AL AR

BL BR

We can compose a data flow analysis model for a cluster of statically-ordered actors that share a slice on a TDM scheduler :

Latency component does not affect local (intra-cluster) communication.

A

TDM

B

LTE PHY – Channel Estimation

•  Graph for 4 TX - 1 RX antennas!

•  4 Coarse ChEst paths!

•  CSDF due to position of reference symbols in subframe!

•  1st, 2nd and 5th OFDM symbols!

CoarseCHEstsource RS

ExtractFreqFilter

TimeFilter

Ports 0-1

TimeFilter

Ports 2-3

MIMO

[2,2,0,2,0,0] [1,1,0,0,1,1]

[0,0,1,1,0,0]

[0,0,1,1,0,0,0,

0,0,0,0,0,0,0]

[1,1,0,0,0,0,0,

0,1,1,0,0,0,0]

WLAN Packet structure and processing

Can Static Data flow handle this?









Src1

2400

Src2

800

Detect

220

Hdemode

920

Src3

2400

FFEnCE

680

CFEnSync

355

Src4

1600

Src5

2400

Src7

4000

Src6

4000

HDecode

920

PDemode

920

PDecode

920

MacCRC

500

MacAnalyse

1000

BuildHeader

500

CodeHeader

920

AckCodeAckMode

920

SIFS

16000

ModHeader

920

5:1

5:1

1:5

1:5

SDF model for WLANWLAN Packet structure and processing









Src1

2400

Src2

800

Detect

220

Hdemode

920

Src3

2400

FFEnCE

680

CFEnSync

355

Src4

1600

Src5

2400

Src7

4000

Src6

4000

HDecode

920

PDemode

920

PDecode

920

MacCRC

500

MacAnalyse

1000

BuildHeader

500

CodeHeader

920

AckCodeAckMode

920

SIFS

16000

ModHeader

920

5:1

5:1

1:5

1:5

SDF model for WLANWLAN Packet structure and processing

We can manually design a worst case model for analysis

Doesn’t work for specification, compilation, or code generation.

It is difficult, time-consuming, error prone…

…And how do we guarantee that the model is correct?

SRDF (HSDF)

MRDF (SDF)

CSDF

DDF

BDF

A1 1 1

SRDF

A1 3 2

MRDF

A1’ 1 1

CSDF A1’’ 2

A1 1 2

BDF

c

3

A1 p m

DDF

1 1 1

q

Non-determinate merge

The right flavor of data flow: Expressivity

2

SRDF (HSDF)

MRDF (SDF)

CSDF

DDF

BDF

SRDF: •  deadlock free •  self-timed execution is bounded by static-periodic schedule with max rate •  static periodic schedule can be built from linear constraints •  linear/convex programming!

CSDF converts to SRDF MRDF converts to SRDF

DDF and BDF are Turing complete, impossible to check even for deadlock freedom in the general case.!

The right flavor of data flow: Analyzability

DF model for Radio: Mode-Controlled Data-flow

•  allows (limited) data-dependent behavior. •  properties somewhat similar to scenario-aware data flow (TUE) •  explicit control •  It is a restriction of integer data flow [Buck]

switch 1 2 3 mc

drop

sync

1 2 3 select1

source

dem dec

sink

1 2 3select2

acq

DVB-T Receiver!3 Modes: !Sync, Decode, Drop!

Our Computation model: Mode-Controlled Data-flow

switch 1 2 3 mc

hdem

sync

1 2select

hdec

pdec

source

dataout

pdem

crc

codeack

modeack

sendheader

sendpayload

shift

2:3 Tunnel 3:4

Tunnel









Our Computation model: Mode-Controlled Data-flow

analysis: monotonic, strict, periodic bound per mode exists. bound self timed execution per mode, compute mode transition overhead normally limited to specific mode sequences of interest. scheduling: quasi-static ordering of actors possible, bounded buffers exist

switch 1 2 3 mc

hdem

sync

1 2select

hdec

pdec

source

dataout

pdem

crc

codeack

modeack

sendheader

sendpayload

shift

2:3 Tunnel 3:4

Tunnel

Quasi-static ordering (extension for MCDF)

•  order of actors inside cluster as static as possible!•  only run-time decision is mode switching!•  mode synchronization among clusters handled by FIFOs !•  broadcast of mode control tokens!

ARM2

EVP ARM1

src

mcMode Switch

1 2 3

sync

hdem

pdem

Mode Switch 2 2 3

hdec

pdec

shift

sink

Sele

ct

2 1

mc

hdemsync

hdec

pdem

shift

1 2Mode Select

pdec

src

sink

1 2 3 Mode Switch

switch

LTE PHY Mode-Controlled Data Flow (simplified)

SRC

CHEST

CDEC

MC

DCID

DDEC

[1,1,0,0,1, 0,0, 1,1,0,0,1,0,0]

CDEC

•  modal behavior combined with cyclo-static behavior •  CHEST estimates for 1st sample after processing 6th •  analysis can handle it, but programming starts becoming difficult •  and what about distributed control? •  still needs more syntactic sugar…

SINK

tunnel

[1,1,0,0,1, 0,0, 1,1,0,0,1,0,0]

select

switch

DROP

To DEC

5

Demonstrator (2009)

Collaboration ST-Ericsson, Nokia, NXP.!All run-time components implemented, including:!•  Predictable local schedulers;!•  Fifo-based communication, self-timed execution!•  Resource manager, w/ runtime task and memory mapping!Best Paper Award SDR Forum 2009.

ARM

SoD streaming

kernel

BB RM Global RM, Config

Manager

ARM

SoD streaming

kernel

Software Architecture - Run-time of Demonstrator

JARM FARM

RTOS

SoD streaming

kernel

Radio functions,

MC L1

EVP

SoD streaming

kernel

Radio processing functions

SoD software

PC

Interconnect

Start/Stop Operational State

Status

Start/Stop Tasks,

Connect Tasks

Fifo Comm

Real-Time

Baseband

SoD NM

Comm Stubs

(Host, RF)

Fifo Comm

Messages

•  data flow: real-time analysis model for concurrent streaming!•  data flow: concurrent programming model!•  budget scheduling: independent behavior (also analysis)!•  automatic generation of analysis model from implementation!•  right flavor of data flow for an application is domain-specific.!

THANK YOU

data flow modeling of radio applicationssander/tutorials/compsoc-sdf3/...dynamic scheduler modeling:...

Documents