A Precise Bandwidth Control Arbitration Algorithm for Hard ... · A Precise Bandwidth Control Arbitration Algorithm for Hard Real-Time SoC Buses 2007/01/24 Bu-Ching Lin, Geeng-Wei

A Precise Bandwidth Control Arbitration Algorithm for Hard Real-Time SoC Buses

2007/01/24

Bu-Ching Lin, Geeng-Wei Lee, Juinn-Dar Huang, Jing-Yang JouDepartment of Electronics Engineering, National Chiao Tung University, Hsinchu, Taiwan

2


OutlineIntroductionPrevious Works

fixed prioritytime division multiple access (TDMA)LotteryRT_lottery

Proposed Arbitration ArchitectureExperimental ResultsConclusions

3


Introduction(1/2)Shared bus is widely used in current SoC designs

master – initiate communication transactionsslave – respond to transactions initiated by mastersarbiter – manage the usage of bus

4


Introduction(2/2)Requirements in different applications

complete transactions of all requests before the corresponding deadlines in real-time applicationstake at least a fixed fraction of total bandwidth in multimedia applications

Difficult to satisfy both real-time and bandwidth requirements simultaneously

an innovative arbitration algorithm is required

5


Previous WorksExisting arbitration algorithms

fixed prioritytime division multiple access (TDMA)LotteryRT_lottery

6


Fixed PriorityAmong the requesting masters, the one with the highest priority gets granted

Prossimple, low hardware cost and easy to implement

Consstarvation problem – the masters with lower priority hardly get the servicelack of control over real-time and bandwidth requirements

7


TDMA (1/2)Execution time is divided into time slots which are statically assigned to masters2nd-level of arbitration is usually adopted to alleviate the wasted time slots

8


TDMA (2/2)Pros

deterministic worst-case response latencyreserved bandwidth for each master

Consdifficult to design time slot sequences in an unpredictablesystemmore slots more bandwidth and shorter latency

what if a master with LOW bandwidth requirement but needs SHORT response latency?

9


LotteryArbiter grants a master stochastically from contending requests

i.e., a weighted random mechanism

M1

M2

M3

M4

T[ 0 ] = M1

T[ 1 ] = M3

T[ 2 ] = M3

T[ 3 ] = M3

T[ 4 ] = M4

T[ 5 ] = M4

T[ 6 ] = M4

T[ 7 ] = M4

T[ 8 ] = XX

T[ 9 ] = XX

Rand[ 0, 8 ) = 5

Request MapTickets(weight)

Grant M4

1

2

3

4

Y

N

Y

Y

1 3 4 = 8

Lottery Manager

++

10


Why Lottery is not suitable in SoC ?Similar requesting rate for each master is assumedWhat if the requesting rates are not similar?

e.g., 3 masters with the same tickets assignment, one with the requesting rate varies from 80% to 40%, the rate of the other 2 is fixed at 40%

Requesting Rate of M1

33%30%28%26%24%M3

33%30%28%26%24%M2

33%38%42%46%49%M1

40%50%60%70%80%

ticket ratio ≠ bandwidth ratioweight tuning is required

similar requesting rate

diverse requesting rate

11


0

5

10

15

20

25

30

35

40

45

50

1:1:1 2:1:1 3:1:1 4:1:1 5:1:1 10:1:1

ticket ratio

ban

dw

idth

(%

)

Latency and Bandwidth in LotteryResponse latency and bandwidth allocation both controlled by the number of tickets

e.g., 3 masters have similar traffic behaviors

0

1

2

3

4

5

6

1:1:1 2:1:1 3:1:1 4:1:1 5:1:1 10:1:1

ticket ratio

aver

age

late

ncy

(cy

cles

)

more tickets shorter response latencymore bandwidth allocation

12


Summary of LotteryPros

good control over bandwidth allocation in network switching applicationsfair average response latency

Consno hard real-time considerationno independent controllability over response latency and bandwidth allocation

13


RT_lotteryA 2-level arbitration algorithm dealing with real-time and bandwidth requirements simultaneouslyThe proposed architecture

1st level – real-time handlerhandles the hard real-time requirements

2nd level – Lottery with tuned weightreserves the bandwidth allocation for each master

14


Real-Time HandlerSimilar to earliest deadline first scheduling (EDF)

the request with earliest deadline and below the warning line gets granted

Deadlinethe time limit for a master to complete a requestmissing the deadline is regarded as the real-time violation

Warning linethe worst case of scheduling the contending requests

15


Weight TuningA ticket redistribution mechanism to meet the required bandwidth by simulation

M1M2

M3

M4M5

M2M3

SmoreM5

M1

Sless

M4Smeet

M2Mmost

SmoreM5

Mleast

Sless

M4Smeet

Tm Tl

Tl’=Tl+TdTm

’=Tm-Td

Initially, Td=Tm/2If any master in Smore or Smet -> Sless

Td = Td / 2

16


Fail Case of Weight Tuning Fail to meet bandwidth requirements due to diversemasters’ requesting rate

e.g., the requesting rate of each master is 80%, 30%, 30%, respectively and each of them requires at least 30% bandwidth

Ticket Assignment of M1, M2 and M3

2322222221212019M3

2322222121212019M2

5354555556575860M1

2:149:1498:146:14616:142:14228:136:13634:133:13344:128:12860:120:120100:100:100

over-allocated bandwidth even with few tickets

weight tuning is not a panacea !

17


Summary of Previous Works

limitation of Weight Tuninghard real-time guaranteeRT_lottery

no real-time considerationno precise bandwidth control

reserved bandwidth allocationfair average latency

Lottery

no hard real-time guaranteeno precise bandwidth control

deterministic worst-case latencyreserved bandwidth allocation

TDMA

no real-time considerationno means for bandwidth control

simplicityarea efficiency

fixed priority

ConsPros

18


RB_lottery Architecture3-level arbitration algorithm

real-time handler – handles the hard real-time requirementsLottery with tuned weight – reserves the bandwidth allocation for each masterbandwidth regulator –provides fine-grained control over bandwidth allocation

19


An Example of RB_lotteryBandwidth regulator monitors the bus traffic

record the transactions of each mastertemporarily block the requests from masters that have already got the required bandwidth in a period

M1

M2

M3

M4

T[ 0 ] = M1

T[ 1 ] = M3T[ 2 ] = M3

T[ 3 ] = M3

T[ 4 ] = XX

T[ 5 ] = XXT[ 6 ] = XX

T[ 7 ] = XX

T[ 8 ] = XXT[ 9 ] = XX

Rand[ 0, 4 ) = 2GrantM3

Y

Lottery Manager

N

Y

Y

Bandwidth Regulator

1

1

1

0

1

2

3

4

1

3

0

0

Real-T

ime

Han

dler

Grant

Tickets

(weight)

Request map

Block signals

1

3

0

4

20


The ImplementationObservation window (w) — the execution time is divided into windows of size w cycles

block the requests of over-served masters temporarilyBandwidth register — the allocated bandwidth in the current window

required bandwidth = 30%

allocatedbandwidth 30% 30% 30% 30%

execution timew w w w

21


RB_lottery Algorithm Flow

1. check whether a new window starts

2. grant the most urgent master

3. stochastically grant an un-blocked master

4. record the transaction cycles

5. check the allocated bandwidth

6. reset all the blocked signals and proceed to the next window

Start

Proceed to the next window?

Release all the blocked masters

Real-Time Handler

Lottery Manager

Record the transaction amounts

of the current granted master

Meet requirement?

Block the request of current

granted master

Yes

Yes

No

NoAny master gets granted?

Yes

No

1

2

3

45

6

22


Experimental EnvironmentTransaction level model in SystemC

different arbitration algorithms are used in the experiments, such as fixed priority, lottery, TDMA + Lottery, RT_lottery, RB_lottery

23


D type (D for Dependency)

D_R type (D for Dependency, R for Real-time)

ND_R type (ND for No Dependency, R for Real-time)

3 Types of Masters

finish

9

request

24 cycle

request

2

finish

9

request

24 cycle

request

2

finish

9 cycle

request

2

grant

5

grant

5

grant

5

request

17

12

12

Example : beat = 4, interval = 15, Rcycles = 10

24


Experiment Setup

10/109/208/407/206/1016/508/50DMaster 3

14/1013/2012/4011/2010/104/501/50DMaster 2

88/20

68/20

13/20

13/20

13/20

9/20

69/1067/4066/2065/1016/508/50ND_RMaster 7

87/40

12/40

12/40

12/40

8/40

86/20

11/20

11/20

11/20

7/20

14/1010/1016/508/50D_RMaster 5

10/106/1016/508/50DMaster 1

interval/prob.beat/prob.type

89/1085/104/501/50ND_RMaster 8

14/1010/104/501/50D_RMaster 6

14/1010/104/501/50DMaster 4

Behavior of masters

Heavy-Traffic Light-Traffic

4 D type masters, 2 D_R type masters and 2 ND_R type masters in the simulation systemHalf of masters are heavy-traffic

25


Performance Comparisons (1/2)Fail cases of different arbitration algorithms

100 random required-bandwidth combinations for each workload102400 simulation cycles for each combination

4474100100100951255100100100901371001001008501810010010080010100100100750010010010070009810010065009510010060

RB_lottery

RT_lottery

TDMA +

LotteryLotteryFixed

PriorityWorkload

(%)

26


Performance Comparisons (2/2)

Summary

good even in extremely high loaded busalways holdRB_lottery

good but still fails in high loaded bus(workload < 75%)always holdRT_lottery

good only in low loaded bus (workload < 60%)no guaranteeTDMA+Lottery

good but weight tuning is requiredno considerationLotterypoorno considerationfixed priority

bandwidth capabilityreal-time capability

Hardware comparisons

5814513449174296215Gate counts

RB_lottery

RT_lottery

TDMA+

LotteryLotteryFixed

Priority

27


128

256

512

1024

2048

8587

8991

9395

0

10

20

30

40

50

60

fail

pat

tern

num

ber

(s)

observation window

workload(%)

Observation Window Comparisons Fail cases in different size of observation window of RB_lottery

100 random required-bandwidth combinations for each workload102400 simulation cycles for each combinationthe size of observation window ranges from 128 to 2048

The size of observation window

2832334457951420243142937710253791024112589000111870001485

20481024512256128

Workload(%)

28


ConclusionsRB_lottery is proposed to provide

hard real-time guaranteefine-grained bandwidth control

The observation window in the bandwidth regulatorthe larger size of observation window, the better controllability over bandwidth requirements

29


Thank you!

Documents

A Precise Bandwidth Control Arbitration Algorithm for Hard ... · A Precise Bandwidth Control Arbitration Algorithm for Hard Real-Time SoC Buses 2007/01/24 Bu-Ching Lin, Geeng-Wei