90 likes | 272 Views
Run-Time Power-Down Strategies for Real-Time SDRAM Memory Controllers. Karthik Chandrasekar 1 , Benny Akesson 2 , and Kees Goossens 2 1 TU Delft and 2 TU Eindhoven, The Netherlands. Karthik Chandrasekar TU Delft. Save Energy @ No Performance Impact. Context here: SDRAM Memories.
E N D
Run-Time Power-Down Strategies for Real-Time SDRAM Memory Controllers Karthik Chandrasekar1, Benny Akesson2, and Kees Goossens2 1TU Delft and 2TU Eindhoven, The Netherlands Karthik Chandrasekar TU Delft
Save Energy @ No Performance Impact Context here: SDRAM Memories
Problem Statement & Proposed Solutions • SDRAMs contribute significantly to SoC energy profile, even when idle. • Powering down impacts performance, due to power-up latencies. • Existing SDRAM memory controllers provide : • Either “Low power consumption” or “Real-Time performance” not “Both”. • Other existing real-time low-power solutions use compile-time info and are not suitable for run-time memory controller use. • We propose : • Run-time power optimization solutions for real-time SDRAM controllers. • We guarantee : • Significant energy savings without impacting bandwidth guarantees. • We support : • SDRAM memory controllers using Predictable arbiters such as: Round-Robin, Time Division Multiplexing, Priority-based arbiters etc.
Arbiters, Requests & Guarantees • Predictable Arbiters such as Round-Robin, TDM, etc. provide: • Maximum Latency Bounds • Minimum Bandwidth Guarantee • Such performance guarantees are based on : • Request Sizes & Service Cycle Length (SCL) • The smallest SCL (min_SCL) defines Scheduling Interval (SI) and Idle SCL. • The longest SCL (max_SCL) defines the guaranteed Net Bandwidth. • Micron 1Gb, DDR3-800 using Closed-Page BC-4, BI-1 for 64B requests.
Deriving Latency-Rate Arbiter Guarantees • A Latency-Rate arbiter guarantees a requester : • Maximum Latency Bounds • Minimum Bandwidth Guarantee • Deriving guarantees for R1 when backlogged using Round-Robin arbiter • Maximum Latency Bound(Θ) = tBLOCK + (x+1) * max_SCL + tREFRESH • Net Bandwidth (Net_BW) = num(max_SCL) * Request Size / tREFI • Minimum Guaranteed Bandwidth (β) = ρ* Net_BW
Proposed Real-Time Power-Down Strategies • Conservative Power-Down • Always powers-up within Scheduling Interval (SI) • Aggressive Power-Down • Powers-up only when required; with Snooping Point @ SI – tPUP • Request misses slot, if it arrives after Snooping point • Only latency bounds increase and bandwidth guarantee is not affected. • What if the request arrives after Snooping point?
Impact on Θand β • Conservative Power-Down • Θ does not change • Max_SCL does not change • Aggressive Power-Down • Θ increases by tPUP • Max_SCL does not change • Speculative Power-Down • Max_SCL increases • Latency Bound(Θ) = tBLOCK + (x+1) * max_SCL + tREFRESH • Net Bandwidth (Net_BW) = num(max_SCL) * request size / tREFI • Bandwidth Guarantee (β) = ρ* Net_BW • Θ increases depending on number of interfering requesters (x) • Net_BW and β decrease significantly depending on increase in max_SCL
Impact on Energy & Performance • 4 Requesters/Apps, Round-Robin, Micron 1Gb, DDR3-800, 64B requests • Average Execution Time Penalty: • Aggressive PD – 0.25% • Speculative PD – 1.32% • Energy Savings: • Conservative PD – 42.1% • Aggressive PD – 51.3% • Theoretical Best PD – 51.4% • Worst-Case Impact: • Θ Increase: • Aggressive PD – 2.4% • Speculative PD – 12.3% • β Decrease: • Aggressive PD – 0.0% • Speculative PD – 12.1%
Summary • Proposed two real-time power-down strategies: • Conservative Latency-Bandwidth-Neutral and Aggressive Bandwidth-Neutral • If memory goes idle, it powers-down (if it is gainful to power-down). • @ Run-time, it checks if the memory can go to or continue to be in power-down. • Evaluated their impact on: • Latency Bounds (Θ) • Bandwidth Guarantee (β) • Compared them against: • Speculative power-down • Theoretical best power-down • Showed impact on: • Real-time performance guarantees • Average-case execution time and energy savings For more details: Please visit my poster!