Trends in Embedded System Design

Size: px

Start display at page:

Download "Trends in Embedded System Design"

Marjorie Garrett
5 years ago
Views:

devices The resulting embedded systems have a large number of IP components run many different

2 Trends in Embedded System Design MPSoC design gets increasingly complex Moore s law enables increased component integration Digital convergence creates a market for highly integrated devices The resulting embedded systems have a large number of IP components run many different independent applications System life time is decreasing Pressure to reduce cost and time to market 2

Example SoC Philips Viper2 (PNX8550) Set-top box Heterogeneous architecture MIPS processor + 2x TriMedia VLI + hardware accelerators Centralized

processors PMA + buses for accelerators 0.

EJTAG M S BOOT M S MIPS P4450 MS M-DCS S PMA-MON S PMA-SEC S PMA-AB M S PCI/XIO S S S S S S S DE IIC1 IIC2 IIC3 USB SMC1 SMC2 M-Gate C-Bridge PMA

3 Example SoC Philips Viper2 (PNX8550) Set-top box Heterogeneous architecture MIPS processor + 2x TriMedia VLI + hardware accelerators Centralized memory with non-uniform memory access latency Central SDAM memory Processors have caches Shared memory communication Interconnect Direct wires for processors PMA + buses for accelerators 0.13 m technology ~50 M transistors > 70 IP blocks 3 DCS-SECM S DCS-CTS M-GIC S M-IPC S CLOCKSS GLOBALS ESET S TM1-DBGS TM2-DBGS UAT1 S UAT2 S UAT3 S EJTAG M S BOOT M S MIPS P4450 MS M-DCS S PMA-MON S PMA-SEC S PMA-AB M S PCI/XIO S S S S S S S DE IIC1 IIC2 IIC3 USB SMC1 SMC2 M-Gate C-Bridge PMA Memory Controller VMPG S VLD TM32 S QVCP2 S DVDD S MBS1 S MBS2 S QTN S QVCP1 S DCS-SECS EDMA S VIP1 VIP2 VPK S S S TSDMA S MS T-DCS MS TM32 S TM1-IPC S TM1-GIC S TM2-IPC S TM2-GIC S M S M S M S M S M S S S S DCS-CT DENC SPDIO AIO1 AIO2 AIO3 GPIO M S TUNNEL MSP1 MSP2

eal-time requirements Embedded applications often have real-time requirements A certain computation must be finished before a deadline There are

application) Deadlines may be safety critical (automotive application) Soft real-time requirements Missing deadlines has moderate impact on quality

4 eal-time requirements Embedded applications often have real-time requirements A certain computation must be finished before a deadline There are three different types of real-time requirements Hard real-time requirements Missing a deadline causes significant quality degradation (media application) Deadlines may be safety critical (automotive application) Soft real-time requirements Missing deadlines has moderate impact on quality Ok to miss some deadlines, but not too many Example: MP3 player No real-time requirements Applications does not have deadlines Example: Graphical user interface 4

5 Verification Applications share resources in the system to reduce cost Processors, memories, interconnect, etc. esource sharing results in interference between applications Timing behaviors of applications in use-case inter-dependent Verification is typically done by system-level simulation All use-cases must be verified instead of all applications Verification must be repeated if applications are added or modified Slow process with poor coverage Verification is costly and effort is expected to increase in future! 5

6 Formal Verification Formal verification is alternative to simulation Provides analytical bounds on latency or throughput Covers all combinations of concurrently running applications Approach requires predictable systems Need performance models of both applications and hardware Application models are not always available Hardware typically not designed with formal analysis in mind Interconnect and SAM controller with performance models exist Problem remains for complex resources, such as SDAM controllers 6

7 Problem Statement Current trends make it increasingly difficult to design embedded systems that satisfy application requirements An SDAM controller is required that satisfies the real-time requirements of embedded applications The controller should reduce verification effort by enabling formal verification of real-time requirements enable independent verification by simulation 7

8 Presentation Outline Introduction SDAM overview Predictable SDAM controller Composable SDAM controller Conclusions 8

9 About SDAM SDAM is an essential system component Enables large storage capacity at low cost DAM cell has 1 transistor and 1 capacitor vs. 6 transistors for SAM A bit is represented by a high or low charge on the capacitor Charge dissipates due to leakage hence the term dynamic AM Capacity of up to a gigabyte per chip SDAM is off-chip memory Long access time compared to SAM Off-chip pins are expensive in terms of area and power SDAM bandwidth is scarce and must be efficiently utilized 9

SDAM Architecture An SDAM is organized in banks, rows and

Interface has a command bus, address bus, and a data bus

pins Typical values DD2/DD3: 4 or 8 banks 8K 65K rows / bank

10 SDAM Architecture An SDAM is organized in banks, rows and columns A row buffer stores a currently active (open) row Interface has a command bus, address bus, and a data bus Buses shared between banks to reduce the number of off-chip pins Typical values DD2/DD3: 4 or 8 banks 8K 65K rows / bank 1K 2K columns / row 4, 8, 16 bits / column MHz 32 MB 1 GB density 10

11 Basic SDAM Operation Memory map decodes address to bank, row, and column ow is activated and copied into the row buffer of the bank ead bursts and/or write bursts are issued to the active row Programmed burst length (BL) of 4 or 8 words ow is precharged and stored back into the memory array 11

12 Timing Constraints Timing constraints determine when cmds can be scheduled Typically minimum delays between commands Different delays for different memories More than 20 constraints to consider Limits the efficiency of memory accesses Precharge, activate and read/write commands before data on bus Parameter Abbr. Cycles ACT to D/ tcd 3 ACT to ACT (diff. banks) td 2 ACT to ACT (same bank) tas 12 ead latency tl 3 D to D - BL/2 12

13 Problem with SDAM The time to serve a request is variable and traffic dependent Is appropriate row is already open in the bank? Is data bus is in read or write mode? Is it time to refresh the memory? This makes it difficult to satisfy latency requirements Offered bandwidth is also variable Problem to guarantee that bandwidth requirements are satisfied orst-case bandwidth very low Less than 40% of peak bandwidth for all DD2 devices Lower for faster memories, such as DD3 Efficiently satisfying hard real-time requirements is challenging! 13

14 Presentation Outline Introduction SDAM overview Predictable SDAM controller Composable SDAM controller Conclusions 14

15 Enabling Formal Verification Predictable systems enable formal verification System in which there is a useful bound temporal behavior Bounding the temporal behavior of a memory controller involves bounding bandwidth and latency Next, we look at how this is done with current controllers 15

16 Statically Scheduled Controllers Some memory controllers are statically scheduled Execute static sequence of SDAM commands Statically scheduled controllers are: predictable Latency of requests and available net bandwidth can be computed Formal verification possible inflexible Cannot adapt to variations in traffic, such as changes in requested bandwidth, read/write ratio etc. not scalable Number of schedules to create, store and verify explodes 16

17 Dynamically Scheduled Controllers Other controllers are dynamically scheduled SDAM commands scheduled dynamically in run-time Dynamically scheduled controllers are: flexible Adapt to variations in traffic efficient Can reorder requests to fit with memory state unpredictable Difficult to provide analytical bounds on bandwidth and latency Typically verified by simulation 17

18 Hybrid Controller e propose a hybrid SDAM controller Combines elements of predictable and flexible memory controllers Increases flexibility compared to existing predictable controllers Does not have to know exact memory traffic at design time Possibly with a reduction in efficiency Efficiency Static controllers Dynamic controllers Predictability Flexibility Hybrid controller 18

Predictable SDAM Predictability through precomputed memory access patterns Patterns are precomputed sub-schedules of SDAM commands There are five types of memory access patterns ead, write, r/w

19 Predictable SDAM Predictability through precomputed memory access patterns Patterns are precomputed sub-schedules of SDAM commands There are five types of memory access patterns ead, write, r/w switch, w/r switch, and refresh patterns Pattern to request mapping: ead request read pattern (potentially first w/r switch) rite request write pattern (potentially first r/w switch) efresh pattern issued when required 19 19

locality equires large requests (64 bytes for 16-bit memory with 4 banks) Memory patterns let us

20 Memory Patterns Patterns enable scheduling at higher level than commands Less state and fewer constraints, making them easier to analyze ead/write patterns are efficient without relying on locality equires large requests (64 bytes for 16-bit memory with 4 banks) Memory patterns let us provide lower bound on bandwidth E.g. 660 MB/s from a 16-bit DD2-400 with peak rate 800 MB/s (82%) ead pattern for DD

21 Pattern generation Memory patterns used to be made by hand Different patterns for different memories All timing constraints considered by designer Time consuming and error prone Now patterns are automatically generated by a tool Created to satisfy all timing constraints, given a specification Three heuristic algorithms Exhaustive algorithm may run for weeks, months, or years Other algorithms find efficient patterns in less than a second 21

Predictable Front-end Arbitration Controller and analysis supports any predictable arbiter Example: ound-obin, TDM, or our own priority-based arbiter Latency computed in number of interfering

22 Predictable Front-end Arbitration Controller and analysis supports any predictable arbiter Example: ound-obin, TDM, or our own priority-based arbiter Latency computed in number of interfering requests Latency bound in clock cycles is easily derived since: equest to pattern mapping is known (scheduling rules) Pattern to cycle mapping is known (length of patterns) Design provides bounds on latency and bandwidth For any combination of DD2/DD3 memory and supported arbiter 22 22

23 Presentation Outline Introduction SDAM overview Predictable SDAM controller Composable SDAM controller Conclusions 23

Isolating Applications Formal verification only applies if there is an application model Composability offers a complementary verification approach System is composable if appl.

24 Isolating Applications Formal verification only applies if there is an application model Composability offers a complementary verification approach System is composable if appl. cannot interfere with each other Cannot affect each others timings by even a single clock cycle Composable systems provide isolation between applications Applications can be composed like pieces in a puzzle 24

Composability Composability simplifies verification for three main reasons: 1. Applications can be verified by simulation in isolation Linear instead of exponential verification complexity 2.

25 Composability Composability simplifies verification for three main reasons: 1. Applications can be verified by simulation in isolation Linear instead of exponential verification complexity 2. Increases simulation speed Only need to simulate application and its required resources 3. Incremental verification process Verification process can start when first application is available 25

26 Existing Approaches There are currently three approaches to composable systems: 1. Not sharing any resources Trivially composable, but prohibitively expensive for SDAM 2. Statically schedule all resource accesses at design time equires a global notion of time Limited to applications that can be statically scheduled 3. Share resources at run-time using TDM equires resource with constant execution time Cannot efficiently satisfy tight latency requirements 26

27 Overview of Approach e propose a fourth approach to composability Idea is to delay responses and flow control until worst case Emulates maximum interference from other applications Makes applications temporally independent Our approach to composability is based on predictability Cannot emulate worst-case interference unless you know what it is orst-case finishing time of requestor in composable system is unaffected when other requestor changes behavior. 27

28 Benefits of Approach Does not have any assumptions on the applications orks with all applications that cannot be formally verified orks with any combination of predictable resource and arbiter Traditional approaches do not support SDAM controllers or priority-based arbitration Composability can be enabled/disabled per appl. at run-time Enables slack to improve performance of non-real-time appl. More efficient than using TDM Does not require constant (worst-case) execution time per request Memory never has to idle 28

29 Composable esource Front End Implemented by adding a Delay Block to the front-end Computes worst-case scheduling time and finishing time at arrival orst-case scheduling time used to delay flow-control signal esponses held in block until worst-case finishing time 29

30 Presentation Outline Introduction SDAM overview Predictable SDAM controller Composable SDAM controller Conclusions 30

Conclusions e propose a predictable and composable SDAM controller Addresses real-time verification problem in SoCs Predictability enables formal verification Covers all possible combinations of

31 Conclusions e propose a predictable and composable SDAM controller Addresses real-time verification problem in SoCs Predictability enables formal verification Covers all possible combinations of applications Achieved by memory patterns and predictable arbitration equires performance model of applications and hardware Composability enables verification by simulation in isolation Only covers simulated traces e emulate worst-case interference from other applications Approach does not have any assumptions on the application 31

32 eferences Predictable and Composable System-on-Chip Memory Controllers Benny Åkesson In: Ph.D. Dissertation February 2010, Eindhoven University of Technology Efficient Service Allocation in Hardware Using Credit-Controlled Static-Priority Arbitration Benny Åkesson, Liesbeth Steffens, and Kees Goossens In: Int'l Conference on Embedded and eal-time Computing Systems and Applications (TCSA), 2009 Composable esource Sharing Based on Latency-ate Servers Benny Åkesson, Andreas Hansson, and Kees Goossens In: 12th Euromicro Conference on Digital System Design (DSD), 2009 eal-time Scheduling Using Credit-Controlled Static-Priority Arbitration Benny Åkesson, Liesbeth Steffens, Eelke Strooisma, and Kees Goossens In: Int'l Conference on Embedded and eal-time Computing Systems and Applications (TCSA), 2008 Predator: A Predictable SDAM Memory Controller Benny Åkesson, Kees Goossens and Markus inghofer In: Int'l Conference on Hardware/Software Codesign and System Synthesis (CODES+ISSS),

Mode-Controlled Dataflow Modeling of Real-Time Memory Controllers

Mode-Controlled Dataflow Modeling of eal-time Memory Controllers Yonghui Li, Hrishikesh alunkhe, Joao Bastos, Orlando Moreira 2, Benny Akesson 3 and Kees Goossens Eindhoven University of Technology, the