a reconfigurable real-time sdram controller for mixed time ...sgoossens/...isss_presentation.pdf ·...

A Reconfigurable Real-Time SDRAM Controller for Mixed Time-Criticality Systems

CODES+ISSS 30-09-2013 Sven Goossens, Jasper Kuijsten, Benny Akesson, Kees Goossens

COBRA – CA104

NEST

Problem Statement

www.compsoc.eu

2/26

SoC

App 1

App 2

App 3

App 4

App 5

map Core 1 Core 2

NoC

SDRAM Peripherals

App 1

App 2

App 3

App 4

App 3

App 5

= Use-case switch

Verification scenarios:

Time

1 2 3 4 5 6

Non-real-time applications

Real-time applications

• Without special measures: • Resource sharing makes functional and timing behavior interdependent • Verification effort grows exponentially with the number of applications

• Can only be done after integration (and may need to be repeated!)

7

The CompSOC approach

www.compsoc.eu

3/26

Physical SoC

Core 1 Core 2

NoC

SDRAM Peripherals

• Virtual execution platforms • Isolation to reduce verification scenarios:

• Predictable virtual platforms − performance isolation (resource budgets) − For analyzable firm real-time applications

• Composable virtual platforms − Complete cycle-level temporal isolation:

For verification by simulation

• Applications run in their own virtual platform • The physical SoC resources are designed to

eliminate interference • Allows independent application development and

verification • We focus on the SDRAM resource

Virtual platform 1

Core

NoC

SDRAM

Core

Contributions

This work has 3 main contributions: 1. Run-time reconfigurable SDRAM controller architecture

• (vs. static, single configuration in existing work) • SystemC and VHDL (FPGA) prototype

2. Predictable and composable service through composable memory patterns

3. Shared through a run-time reconfigurable TDM arbiter, allowing reallocation of TDM slots in a predictable and composable way

www.compsoc.eu

4/26

Outline

www.compsoc.eu

5/26

Introduction

Background

Reconfigurable TDM Arbiter

Experiments

Conclusions

Composable Memory Patterns

Reconfigurable Controller Architecture

SDRAM

www.compsoc.eu

6/26

Galaxy S4 mainboard (Source: gizmondo.com)

row buffer

bank

read write

prechargeactivate(open) (close)

• SDRAM consists of multiple banks, that each have rows and columns • To read/write, a row in a bank first has to be activated • Each bank can have only one active row • After reading/writing, a row has to be precharged before another row can be activated

Data:

SDRAM Accesses

www.compsoc.eu

7/26

B A

D C row

s

Bank 1:

ACT RD A WR C WR D PRE RD B ACT … … … … … …

Bank 2:

…

Bank 0:

column

Commands:

4 cc 19 cc 22 + 17 + 19 = 58 cc 12 cc

Swap data bus direction

A B C D

Naïve command scheduling low worst-case efficiency

Efficiency (excluding refresh): #cc_data / #cc_cmds ≈ 17%

• For an LPDDR3-1600 (800 MHz):

Predictable SDRAM Patterns

www.compsoc.eu

8/26

A B C D E F G H

row

s

Bank 1:

Read pattern

I J K L Bank 2:

…

Bank 0:

column

76 cc

Write pattern

A B Data:

C D E … O P

Switch pattern

…

Decrease access irregularity, increase granularity

4 cc 76 cc

Worst-case efficiency: #cc_data / #cc_cmds = 82 %

• Basic idea: generate valid command series or patterns at design time, schedule them at run time.

• ( Note: Switching patterns consist only of NOPs )

Outline

www.compsoc.eu

9/26

Introduction

Background: Predictable SDRAM


Experiments

Conclusions



Reconfigurable Controller Architecture 10/26

Run-time reconfiguration infrastructure (memory mapped)

Reconfigurable TDM arbiter (predictable and composable during reconfiguration)

Reconfigurable back-end, using composable patterns. • Patterns are reprogrammable at run time. • Different pattern different worst-case bandwidth, latency and power trade-off. • Allows different trade-off per use case. Details of the back-end, and FPGA synthesis results In paper

SDRAMback-endSDRAMback-end

Resource front-endResource front-end

Configuration BusConfiguration Bus

WidthConverter

WidthConverter

WidthConverter

WidthConverter

Req./Resp.queue

Req./Resp.queue

AtomizerAtomizer

TDMArbiterTDM

Arbiter

Req./Resp.queue

Req./Resp.queue

SD

RA

M

Resource B

us

Memory client 1

Memory client 2

Configuration data

AtomizerAtomizer

PH

Y

Outline

www.compsoc.eu

11/26

Introduction



Experiments

Conclusions




www.compsoc.eu

12/26

Read pattern

Write pattern RtW

Write pattern WtR Read

pattern RtW Idle

Predictable patterns have non-constant slot sizes not composable

Predictable patterns:

Read pattern Write pattern Read pattern Idle

Composable patterns:

Eliminate switching patterns, make remaining pattern lengths equal

• Goal: make SDRAM accesses composable complete isolation of clients slots always start at the same time

Composable Patterns Generation

www.compsoc.eu

13/26

Write pattern

WtR Read pattern

RtW

Naïve solution:

merge, max:

Write pattern

Read pattern

Proposed method:

Added NOPs

slice:

Write pattern

Read pattern

• (Note: we only slice within the switching patterns, which contain only NOPs) • Minimizes impact on worst-case efficiency to 1 cycle (in case the total length is odd) • (In paper) For a range of memories: average efficiency loss of 0.22% (2.6% max)

Outline

www.compsoc.eu

14/26

Introduction



Experiments

Conclusions



Reconfiguring a TDM Arbiter

www.compsoc.eu

15/26

A B C D E

TDM table, 5 slots, 5 applications (A-E)

A B C D E A B C D E A B C D E

A B C D E A B C D E F B C D A F B C D A

Reconfiguration event: de-allocate E, move A, add F

1. De-allocate finished app.

2. Move persistent app.

3. Allocate new app.

Naive reconfiguration flow:

Time

Reconfiguring a TDM Arbiter

www.compsoc.eu

16/26

A B C D E

TDM table, 5 slots, 5 applications (A-E)

A B C D E A B C D E A B C D E

A’s request arrives (just too late for the start of the slot)

Response time: 6 slots

A B C D E A B C D E B C D A B C D A

A’s request arrives Response time: 10 slots > 6 slots

Reconfiguration event: move A’s slot

Can this effect violate the performance guarantees given to A?

TDM Latency-rate Server

www.compsoc.eu

17/26

A B C D A B C D A B C D A B C D

Worst-case arrival

Serv

ice

units

Time

Θ = 6 ρ = 1/5

• Guarantee based on two parameters: • Client gets a minimum allocated rate (ρ), • After a maximum service latency (Θ)

• (As long as the client produces enough requests to stay busy)


We model the reconfiguration as a hand-over between two independent latency-rate servers.

www.compsoc.eu

18/26

Serv

ice

units

Time

Switch off orange server

Switch on blue server

Orange guarantee

Received service (orange + blue)

1. Deallocate finished app.

2a. Move: allocate new slots

3. Allocate new app.

2b. Move: de-allocate old slots

• The distance between step 2a and 2b matters


www.compsoc.eu

19/26

Serv

ice

units

Time



Orange guarantee

Received service (orange + blue)


• If the distance between the “switch on” and “switch off” event is at least Θ, then the original guarantees remain valid during reconfiguration.

• The paper contains a mathematical proof for this property and a description of the hardware implementation.

www.compsoc.eu

20/26

Serv

ice

units

Time



Orange guarantee, Received service (orange + blue)

Θ

Outline

www.compsoc.eu

21/26

Introduction



Experiments

Conclusions



Composablity Experiment (FPGA)

www.compsoc.eu

22/26

• Two MicroBlaze cores (MB1, MB2) connected to a DMA • synthetic application generates traffic at 90 MB/s • record timestamps in request/response buffers

• Six experiments: • Using 1) Predictable patterns, 2) Composable patterns:

A) Reference run:

B) Interference run:

C) Reconfiguration run:

1 1 1 1

1 1 1 1 2 2 2 2

1 1 1 1 2

1 1 1 1 2 2

32 μs

MB1 referenceMB1 interference

MB1 reconfiguration

Predictable patterns (FPGA)

www.compsoc.eu

23/26

0

Resp

onse

tim

e [n

s]

Arrival time [μs]

• MB2’s behavior varies wildly across runs, as a result of the interference from MB1 Not composable (verification for MB2 has to take MB1 in to account)

MB1 referenceMB1 interference

MB1 reconfiguration

Composability Experiment (FPGA)

www.compsoc.eu

24/26

Resp

onse

tim

e [n

s]

Arrival time [μs]

• MB2’s behavior is constant across runs, MB1 has no influence Composable (can be verified independently)

Outline

www.compsoc.eu

25/26

Introduction



Experiments

Conclusions



Conclusions

• Run-time reconfigurable SDRAM controller architecture. • Memory-mapped configuration ports to various components. • FPGA & SystemC implementation.

• Predictable and composable service through composable memory patterns • Each access has the same length, no explicit switching patterns. • Max. 2.6% overhead

• TDM reallocation in a predictable and composable way.

• by enforcing a minimal distance between allocation and de-allocation of slots.

• Demonstrated on FPGA

www.compsoc.eu

26/26

• For further information: www.compsoc.eu

Sven Goossens <[email protected]> Jasper Kuijsten <[email protected]> Benny Akesson <[email protected]> Kees Goossens <[email protected]>

www.compsoc.eu

27/23

Electronic Systems Group Electrical Engineering Faculty

Eindhoven University of Technology

a reconfigurable real-time sdram controller for mixed time ...sgoossens/...isss_presentation.pdf ·...

Documents