PRET DRAM Controller: Bank Privatization for Predictability and Temporal Isolation

Transcription

1 PRET DRM Controller: Bank Privatization for Predictability and Temporal Isolation ungjun Kim Columbia University Edward. Lee UC Berkeley Isaac Liu UC Berkeley Hiren D. Patel University of Waterloo Jan Reineke UC Berkeley <speaker> CODE+I as part of EWEEK 2011 Taipei, Taiwan, October 10th, 2011

2 Predictability and Temporal Isolation Many embedded systems are real-time systems Memory hierarchy has a strong influence on their performance: Need for Predictability Trend towards integrated architectures: Need for Temporal Isolation ide airbag in car, Reaction in <10 mec Crankshaft-synchronous tasks, Reaction in <45 µec udio + video playback with latency and bandwidth constraints Reineke et al., Berkeley 2

3 Outline Introduction DRM Basics Related Work: Predator and MC PRET DRM Controller: Main Ideas Evaluation Integration into Precision-Timed RM Reineke et al., Berkeley 3

4 Outline Introduction DRM Basics Related Work: Predator and MC PRET DRM Controller: Main Ideas Evaluation Integration into Precision-Timed RM Reineke et al., Berkeley 4

5 Memory Hierarchy: Dynamic RM vs tatic RM RM Fast Low Latency Low Capacity DRM low High Latency High Capacity from Hennessy and Patterson, Computer rchitecture: Quantitative pproach, Reineke et al., Berkeley 5

6 Dynamic RM Organization Overview DRM Cell Leaks charge Needs to be refreshed (every 64ms for DDR2/DDR3) therefore dynamic DRM et of DRM banks + Control logic I/O gating ccesses to banks can be pipelined, however I/O + control logic are shared addr+cmd DIMM Bit line Word line Transistor Capacitor Bank Row ddress Row Decoder DRM rray ense mplifiers and Row Buffer Column Decoder/ Multiplexer command chip select address Control Logic Mode Register ddress Register DRM Row ddress Mux Refresh Counter Bank Bank Bank Bank I/O Gating I/O Registers + Data I/O data 16 data 64 data 16 data 16 data 16 data 16 chip select 0 chip select 1 DRM Bank = rray of DRM Cells + ense mplifiers and Row Buffer haring of sense amplifiers and row buffer DRM Module Collection of DRM s Rank = groups of devices that operate in unison Ranks share data/address/ command bus Rank 0 Rank 1 Reineke et al., Berkeley 6

7 DRM Memory Controller Translates sequences of memory accesses by Clients (CPUs and I/O) into legal sequences of DRM commands Needs to obey all timing constraints Needs to insert refresh commands sufficiently often Needs to translate physical memory addresses into row/column/ bank tuples CPU1... CPU1 Interconnect + rbitration Memory Controller DRM Module I/O Reineke et al., Berkeley 7

8 Dynamic RM Timing Constraints DRM Memory Controllers have to conform to different timing constraints that define minimal distances between consecutive DRM commands. lmost all of these constraints are due to the sharing of resources at different levels of the hierarchy: addr+cmd DIMM Bit line Word line Transistor Capacitor Bank Row ddress Row Decoder DRM rray ense mplifiers and Row Buffer Column Decoder/ Multiplexer command chip select address Control Logic Mode Register ddress Register DRM Row ddress Mux Refresh Counter Bank Bank Bank Bank I/O Gating I/O Registers + Data I/O data 16 data 64 data 16 data 16 data 16 data 16 chip select 0 chip select 1 Needs to insert refresh commands sufficiently often Rows within a bank share sense amplifiers Banks within a DRM device share I/O gating and control logic Rank 0 Rank 1 Different ranks share data/address/ command busses Reineke et al., Berkeley 8

9 General-Purpose DRM Controllers chedule DRM commands dynamically Timing hard to predict even for single client: Timing of request depends on past requests: Request to same/different bank? Request to open/closed row within bank? Controller might reorder requests to minimize latency Controllers dynamically schedule refreshes Non-composable timing. Timing depends on behavior of other clients: They influence sequence of past requests rbitration may or may not provide guarantees Reineke et al., Berkeley 9

10 General-Purpose DRM Controllers B1.R3.C2 B1.R4.C3 B1.R3.C5 Memory Controller R B1.R3 C B1.C2 R B1.R4 C B1.C3 R B1.R3 C B1.C5? R B1.R3 C B1.C2 C B1.C5 R B1.R4 C B1.C3 Reineke et al., Berkeley 10

11 General-Purpose DRM Controllers Thread 1 Thread 2 B1.R3.C2 B2.R4.C3 tore B4.R3.C5 B3.R3.C2 B3.R5.C3 tore B2.R3.C5 rbitration B1.R3.C2 B3.R3.C2 B3.R3.C2 B1.R3.C2 B2.R4.C3 tore B4.R3.C5 B3.R5.C3 tore B3.R5.C3 B4.R3.C5 tore B2.R3.C5? Memory Controller Reineke et al., Berkeley 11

12 Outline Introduction DRM Basics Related Work: Predator and MC PRET DRM Controller: Main Ideas Evaluation Integration into Precision-Timed RM Reineke et al., Berkeley 12

13 Predictable DRM Controllers: Predator (Eindhoven) and MC (Barcelona) CPU1 Closed-page policy: timing independent of previously accessed row pread each request over all banks, pipeline accesses to banks. tatically precomputed sequences for writes, reads, write->read, read->write, refresh.... CPU1 Interconnect + rbitration Memory Controller DRM Module I/O Predictable and/or composable arbitration: Predator: CCP MC: TDM Reineke et al., Berkeley 13

14 Predictable DRM Controllers: Predator (Eindhoven) B1.R3.C2 B1.R4.C3 tore B1.R3.C5 Predictable Memory Controller: Predator Read Pattern Read Pattern R/W Pattern Write Pattern Closed-page policy: timing independent of previously accessed row pread each request over all banks, pipeline accesses to banks. increases access granularity tatically precomputed sequences for writes, reads, write->read, read->write, refresh. Reineke et al., Berkeley 14

15 Predictable DRM Controllers: Predator (Eindhoven) and MC (Barcelona) Thread 1 Thread 2 B1.R3.C2 B3.R3.C2 B3.R5.C3 tore B2.R3.C5 Predictable and/or Composable rbitration (e.g. time-division multiple access) B1.R3.C2 B3.R3.C2 B3.R5.C3 tore B2.R3.C5? Memory Controller Reineke et al., Berkeley 15

16 Outline Introduction DRM Basics Related Work: Predator and MC PRET DRM Controller: Main Ideas Evaluation Integration into Precision-Timed RM Reineke et al., Berkeley 16

17 PRET DRM Controller: Three Innovations Expose internal structure of DRM devices: Expose individual banks within DRM device as multiple independent resources CPU1... CPU1 Interconnect + rbitration PRET DRM Controller DRM Bank DRM Module DRM Module DRM Module I/O Defer refreshes to the end of transactions llows to hide refresh latency Perform refreshes manually : Replace standard refresh command with multiple reads Reineke et al., Berkeley 17

18 PRET DRM Controller: Exploiting Internal tructure of DRM Module Consists of 4-8 banks in 1-2 ranks hare only command and data bus, otherwise independent Partition into four groups of banks in alternating ranks Cycle through groups in a time-triggered fashion Rank 0: Bank 0 Bank 1 Bank 2 Bank 3 uccessive accesses to same group obey timing constraints Reads/writes to different groups do not interfere Rank 1: Bank 0 Bank 1 Bank 2 Bank 3 Provides four independent and predictable resources Reineke et al., Berkeley 18

19 PRET DRM Controller: Exploiting Internal tructure of DRM Module B1.R3.C2 B1.R4.C3 tore B1.R3.C5 PRET DRM Controller Read Pattern Read Pattern Write Pattern Reineke et al., Berkeley 19

20 Pipelined Bank ccess cheme Cycles Resource/Rank 0/0 1/1 2/0 3/1 0/0 1/1 Command Bus R C N O P R C N O P R C RED WRITE RED N O P N O P N O P N O P N O P R C N O P R C N O P... Rank 0 Resource 0+2 R Posted- C with tl=2 C Posted- C R Posted- C P R E C R Posted- C P R E C... uto-precharge uto-precharge Rank 1 Resource 1+3 R C uto-precharge P R E R... Data Bus Burst from Rank 0 Burst to Rank 1 Burst from Rank 0... trcd tcl trcd twl trp twr tfw Figure 2: The periodic and pipelined access scheme employe Reineke et al., Berkeley 20

21 PRET DRM Controller: Manual Refreshes Every row needs to be refreshed every 64ms Dedicated refresh commands refresh one row in each bank at once We replace these with manual refreshes through reads Improves worst-case latency of short requests Dedicated refresh commands vs refreshes through reads. time (refresh latencies not to scale) time Reineke et al., Berkeley 21

22 PRET DRM Controller: Defer Refreshes Refreshes do not have to happen periodically Refresh every row at least every 64 ms chedule refreshes slightly more often than necessary Enables to defer refreshes <= = ms time DM <= 64 ms time Reineke et al., Berkeley 22

23 General-Purpose DRM Controller vs PRET DRM Controller General-Purpose Controller bstracts DRM as a single shared resource chedules refreshes dynamically chedules commands dynamically Open page policy speculates on locality PRET DRM Controller bstracts DRM as multiple independent resources Refreshes as reads: shorter interruptions Defer refreshes: improves perceived latency Follows periodic, timetriggered schedule Closed page policy: access-history independence Reineke et al., Berkeley 23

24 Outline Introduction DRM Basics Related Work: Predator and MC PRET DRM Controller: Main Ideas Evaluation Integration into Precision-Timed RM Reineke et al., Berkeley 24

25 Conventional DRM Controller (DRMim2) vs PRET DRM Controller: Latency Evaluation Varying Interference: Varying Transfer ize: latency [cycles] 3,000 2,000 1, Interference [# of other threads occupied] 4096B transfers, conventional controller 4096B transfers, PRET controller 1024B transfers, conventional controller 1024B transfers, PRET controller Figure 9: Latencies of conventional and PRET memory con- average latency [cycles] 3,000 2,000 1,000 0 Conventional controller PRET controller 0 1,000 2,000 3,000 4,000 transfer size [bytes] Figure 10: Latencies of conventional and PRET memory con- Reineke et al., Berkeley 25

26 PRET DRM Controller vs Predator: nalytical Evaluation latency [cycles] Manual refreshes Private resources in backend Hiding refreshes size of transfer [bytes] hared Predator BL =4w/ refreshes DL r 4,4(x): hared PRET BL =4w/ refreshes DL r (x): PRET BL =4w/ refreshes DL r (x): PRET BL =4w/o refreshes Predator: abstracts DRM as single resource uses standard refresh mechanism PRET controller improves worst-case access latency of small transfers Figure 7: Latencies for small request sizes up to 256 bytes un Reineke et al., Berkeley 26

27 PRET DRM Controller vs Predator: nalytical Evaluation latency [cycles] 800 Benefit of burst length 8 over burst length ,024 1,280 1,536 1,792 2,048 size of transfer [bytes] hared Predator, BL =4, accounting for all refreshes DL r (x): PRET, BL =4, accounting for all refreshes hared Predator, BL =8, accounting for all refreshes DL r (x): PRET, BL =8, accounting for all refreshes Figure 8: Latencies of Predator and PRET for request sizes up Less of a difference for larger transfers Predator provides slightly higher bandwidth due to more efficient refresh mechanism Reineke et al., Berkeley 27

28 Outline Introduction DRM Basics Related Work: Predator and MC PRET DRM Controller: Main Ideas Evaluation Integration into Precision-Timed RM Reineke et al., Berkeley 28

29 Precision-Timed RM (PTRM) rchitecture Overview Hardware Hardware Hardware thread Hardware thread thread thread registers scratc h pad memory memory memory memory I/O devices Interleaved pipeline with one set of registers per thread RM scratchpad shared among threads DRM main memory, separate banks per thread Thread-Interleaved Pipeline for predictable timing without sacrificing high throughput One private DRM Resource + DM Unit per Hardware Thread hared cratchpad Instruction and Data Memories for low latency access Reineke et al., Berkeley 29

30 Conclusions and Future Work Temporal isolation and improved worst-case latency by bank privatization How to program the inverted memory hierarchy? Raffaello anzio da Urbino The thens chool Lee, Berkeley 30

31 References Related Work on Memory Controllers: M. Paolieri, E. Quiñones, F. Cazorla, and M. Valero, n analyzable memory controller for hard realtime CMPs, IEEE Embedded ystems Letters, vol. 1, no. 4, pp , B. kesson, K. Goossens, and M. Ringhofer, Predator: a predictable DRM memory controller, in CODE+I. CM, 2007, pp Work within the PRET project: [CODE 11] Jan Reineke, Isaac Liu, Hiren D. Patel, ungjun Kim, Edward. Lee, PRET DRM Controller: Bank Privatization for Predictability and Temporal Isolation, International Conference on Hardware/oftware Codesign and ystem ynthesis (CODE+I), October, [DC 11] Dai Nguyen Bui, Edward. Lee, Isaac Liu, Hiren D. Patel, Jan Reineke, Temporal Isolation on Multiprocessing rchitectures, Design utomation Conference (DC), June, [silomar 10] Isaac Liu, Jan Reineke, and Edward. Lee, PRET rchitecture upporting Concurrent Programs with Composable Timing Properties, in ignals, ystems, and Computers (ILOMR), Conference Record of the Forty Fourth silomar Conference, November 2010, Pacific Grove, California. [CE 08] Ben Lickly, Isaac Liu, ungjun Kim, Hiren D. Patel, tephen. Edwards and Edward. Lee, " Predictable Programming on a Precision Timed rchitecture," in Proceedings of International Conference on Compilers, rchitecture, and ynthesis for Embedded ystems (CE), Piscataway, NJ, pp , IEEE Press, October, Reineke et al., Berkeley 31