Automotive Trends: Architecture and Technology

Transcription

1 June, 2010 Automotive Trends: Architecture and Technology FTF-AUT-F0341 Davide Santo System Architect

2 The lecture will: Describe the primary drivers expected in the next generation of automotive embedded microcontrollers Introduction Help focus on the key challenges for the automotive system architect Provide references and concepts to address the challenges identified Give a brief look into the technology offering Presenter: Davide SANTO System Architect for Power 32-bit Automotive μcontroller Exprience: Chassis & Safety, Powertrain, Infotainment 2

3 The lecture shall provide means to: Lecture Objectives Identifying the key technical drivers for architectural design of embedded flash mcontroller with special focus on computational bandwidth, low power and safe systems Propose technical approaches and technology options to satisfy the demands for the next generation system 3

4 Agenda Technology drivers Architectural Outlook Memory & IP Summary 4

5 Market driving trends Standardization AutoSAR Security standards Functional Safety Energy Efficiency Reduction of CO 2 Lightweight auto trend Pollution reduction Complexity Management Distributed computing Multiplicity of actuators / sensor Delocalization of application management Enablement & Differentiation Reliability through quality Flexibility of architecture Availability over safety Time-to-Market Secure technology Scalable platform Software and hardware abstraction 5

6 Embedded μcontroller Architecture 90 s 2000 s 2010 s Real Time HW solution SW developed around it MPC555 Holistic Integration Of HW architecture. SW made easier: MPC55xx & MPC56XX s-cube : Soft, Safe & Secure SW centered solution 32bit µc with peripherals 2MB Embedded Flash Embedded automotive application μcontrollers are evolving from hardware to software centered solutions Value is added via the coherent integration of IPs and simplification of user model One Platform to cover multiple applications 6

7 Today s Challenges Architcture of μcontroller for auto nonvolatile memory based application: Single/dual core or with little usage of I/O proc. Co-Location of application management and real time actuation Communication between mcontroller limited in bandwidth and flexibility Not functionally safe or heavily software dependent for safety Challenges of today s architecture: Usability of mcontroller Learning Curve plus technical complexity Portability of Code Capability to support many suppliers through multiples applications Time to Market Change of software/hardware needs requalification Size & Power of mcontroller Total cost of ownership DMA App Core FlexRay Interconnect NVM SRAM I/O COMS A/D 7

8 Tomorrow s Projections Architecture of μcontroller for 2010 and beyond: Multicores to manage performance-power trade off Delocalization of application management from actuation High BW communication between application domains Must be green (less power = less emission) Functional safety becoming pervasive Security of software AUTOSAR with strong hardware abstraction Architecture evolution: Divide & Conquer : Separation of computational and peripheral shell Simplification of periphery (leaner and simpler usage model) and multiplication (many but smaller) Sharing of applications on same domain controller (thus more performance required) Focus on smaller size and critical paths on each IP Computational Shell App Core App Core Safe Core FlexRay Masters eg Security Robust NVM Robust SRAM IO Core DMA Interconnect NVM SRAM IO Peripheral Shell COMS A/D 8

9 The Frugal Engineer Is it better to do The Same with Less or More with the Same? Lightweight (small size) cars fuel the growth in emerging markets Electrification of the car is slowly happening re-thinking of the automotive network Domains partitioning enforces integration (less ECU at same function) Energy concerns is higher but not yet critical at customer level Frugal Engineering : neither 2 nd best nor less quality but an art of thinking to innovate by reduction of complexity and simplification of needs Do we need 64-bit computational capability across the board? Do we need multiple ways for each cache? Can we adopt a hierarchical memory structure? 9

10 Three fold path 1.) Technology Performance : ~ 15% frequency increase as same power vs. 3-5x mkt. request Multicores, custom accelerators, intelligent periphery 90 nm Future 2.) Size: 40-50% reduction at same feature set or ~same size with additional features vs. reliable IP Higher density and distributed hierarchy for memories, smaller gates, distributed function, multiple smaller IP 3.) Power: -50% power for same application target but with increase performance vs. -30% at same feature set Multi-Vth, dynamic voltage scale, smart clock-tree, independent frequency domains 10

11 10000 Logic Density Technology Scaling Guidelines Analog & I/O MPC MPC nm 90nm 65nm 40nm 28nm Scale linearly (0.5 areal) More functionality More power (run & stand-by) Reduced shrink factor (~0.7 areal) High voltage Manufacturability Size Volatile Memories 10 Nonvolatile Memories Size nm 90nm 65nm 40nm 28nm Scale linearly (~ 0.5 areal) Fast RAM impacts power Reduced shrink factor (~ 0.7 areal) Reliability and robustness 11

12 Very aggressive market power targets Low Power Design OEM/Tier1 asking for -40% reduction to allow for eco-sensitive design to coexist with demand for additional features Dynamic-leakage partition is 66%-33% Leakage weight increases with technology scaling. Power management complexity very high Process variation: worst case current much higher than average Automotive requires guarantee, not peak value Performance vs. power trade-off in worst case Design techniques Leakage: Power gating & multiple power down modes Scalable voltage supply Low Voltage islands Smaller devices better than large Dynamic: Clock gating & reduced signal toggling Internal clock sources Switch mode power supply Autonomous peripherals Clock tree optimization 12

13 Power Market place requesting 30-50% reduction in power over existing architectures Performance Market place looks for 3-5x performance over actual architectures Functional Safety ASIL-C & ASIL-D compliance with small cost adder. Low to extreme low FIT level for computational shell Lower Total Cost of Ownership Compete on lower ASP Reduce development costs of customer system Faster time to market Freescale Architectural Drivers 13

14 Functional Safety Evolution Over past decade functional safety demand has increased dramatically in Automotive market Freescale product development activity in this area has reflected market dynamics Trend towards functional safety qualification at component level Strong emphasis on dependability 14

15 Safer Architecture Cores and memories: Identify safe function and set boundary for application and real-time management Manage additional application specific needs (e.g., FlexRay, special functions) Safe interconnect fabric (by duplication, by diverse check) Robust memories and safe controllers Safe IO bridges and periphery Increase of Availability Fail Notif. T sens Power Monitor Clock Monitor SPI CAN LIN UART Timers Sensor Input A/D Ext. Bus I/F Mandated: Higher Performance. Lower Power High Safety Integrity 15

16 Computation and Power Multicore Strong scalability Increase performances Manage MHz/Watt trade-off Perf Single Core Power Perf Power Nx Core Perf Power Single Core Performance N x core Nx frequency Time Allow to diversify safety strategy Support independent software SWT MCM S INTC PowerPC e200 SPE VLE FPU MMU VLE CACHE PowerPC e200 SPE VLE FPU MMU VLE CACHE SWT MCM S INTC Debug JTAG Nexus PowerPC e200 SPE VLE FPU/DSP MMU VLE CACHE SWT MCM S INTC Masters Safety IP Peripherals Safe Interconnect Fabric Memory Protection Unit Easy to use program model Simple and lightweight to save power Flexible integration at top level Safety IP TSENS I/O Bridge Vital Support/Safety Communications PMU IO Mgtm LIN 2 x LINFlex 3 x DSPI NVM (ECC) FlexCAN SRAM (ECC) Diagnostics 3 x (Timers) etimer Actuation/Sensing Actuators 2 x FlexPWM (PWM) Sync CTU IP I/O Bridge Sensor 2 x (A/D) ADC I/O System 16

17 Vertical split: centered around software application Computational shell for application management (OEM software) Peripheral shell for IO management, sensor and actuation control (TIER1 software) Enable software partitioning PowerPC SWT e200 SWT MCM PowerPC SPE MCM S e200 VLE S FPU MMU INTC VLE CACHE I/O Bridge INTC SPE VLE FPU MMU VLE CACHE PowerPC SWT e200 MCM PowerPC SWT SPE e200 S MCM VLE SPE FPU MMU VLE VLE FPU CACHE MMU VLE CACHE INTC S Safe XBar Memory Protection Unit NVM (ECC) INTC PowerPC e200 SPE VLE FPU/DSP MMU VLE CACHE SRAM (ECC) SWT MCM S INTC Debug JTAG Nexus Masters Safe XBar Memory Protection Unit I/O Bridge Horizontal split: centered around AUTOSAR One Core will implement the full OS Interprocessor Comunication via RTE Each OS Application may run equally on each Core Vital Support/Safety Communications Safety IP Application Software Component Operating System TSENS PMU IO Mgtm Application Software Component System Services Onboard Device Abstraction LIN 2 x LINFlex 3 x DSPI Application Layer AUTOSAR Runtime Environment (RTE) Memory Services Memory Hardware Abstraction FlexCAN Microcontroller Diagnostics (Timers) etimer Communication Services 3 x Communication Hardware Abstraction Actuation/Sensing Actuators 2 x FlexPWM (PWM) I/O Hardware Abstraction Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers Sync CTU IP Sensor 2 x (A/D) ADC Application Software Component Application Software Component Complex Driver I/O System Basic Software 17

18 Trends in Embedded SRAM Automotive SRAM bit cells will be designed in order to maintain sufficient design margin Bit cells will be slightly upsized versions of standard logic-baseline 6T bit cells at each technology node Voltage scaling of the SRAM bits cells will lag voltage scaling of the logic Addition of more power management modes to reduce active and leakage power; In addition, improve integration with System-on-Chips (SoC) to enable utilization of sophisticated power management schemes Introduction of additional fault tolerant design techniques 18

19 SRAM Enhancement through Technologies 130 nm 90 nm Next Node Zero Defect Test Modes BIST stress modes BIST Stress, burn-in modes Programmable BIST Stress, burn-in modes Scan LBIST support Design Implementation 1.5V supply 1.2V supply 1.0/1.2V supply Current sensing Voltage sensing Voltage sensing Targeted compilers for performance and low power Design techniques from proven 45 nm compilers Fault tolerant features SoC level ECC SoC level ECC SoC level ECC Address fault detection Power Management Single power supply Periphery shut down Array source bias Periphery shutdown Array source bias DVFS support (1V logic, 1.2V array) HVT & SVT bit cell options 19

20 Trends in Embedded NVM Conventional flash cells continue to scale to 55 nm maintaining performance while enhancing critical features (Program/erase, etc.) Split-gate flash cells are of increasing interest across the application space. The industry is examining alternative cell technologies for long term roadmap MRAM: Magneto-Resistive RAM Phase change RRAM: Electrically alterable resistor cell Freescale strategy is to continue scaling our flash technologies while evaluating the best new approach. Use of System-in-package with primary memory and logic functions on separate chips is also considered as a path to prolong the life span of a technology node 20

21 NVM enhancements through Technologies 5 generations of automotive flash (3 generations with HCI program + channel erase) have enabled development of robust flash design features: 130 nm 90 nm Next Node Zero Defect Test Modes ZD test automation through BIST Code execution testing using BIST Refined test modes Improved parametric testing Further refinements planned Design Implementation Scan testing of logic Robust timing analysis Random + directed simulation Improved HV management Improved analog observability Internally regulated HV supplies Program and erase time improvements Improved analog modeling for mixed signal Read disturb tolerant addressing Fault tolerant features ECC ECC single bit flag ECC diagnostic In-system array integrity test Factory margin modes Enhanced margin modes 21

22 Core & Computational aggregates IP Development trends Multiple core, smaller, lesser power, distributed functionalities (DSP, Safety, Security) Focus on Availability and Recoverability (self-correcting units, Built-in self test) Network link and Interprocessor communication Standard Protocol are mandated Low Pin Count, low Power, high BW interprocessor Communication (ex: DigRF, Aurora) Leverage Ethernet :easy-to-use connectivity Analog: A/D, D/A PLL, I/O, Oscillators Addressing both dynamic and static components of power High Reliability over lifetime at extreme condition (Increased Tjunction, EMI, Latch-up, ESD) Simplification of Porgramming Model (no asm, auto code gen. Support, less complex mutli-ip) Digital: Timer, Comm. Peripheral, Intelligent IP SW centered IP development (MPU, Register Protection, Atomic Access, Mutex) Continuum of Advanced Timers (AST and Electrical Motor Control) Enhancement via new Sensor I/F (SENT, PSI5/DSI, Video framer, MPEG/JPEG encoder etc.) Low Power Digital design (clock gating, mutliple voltage and frequency domains) Error Management Units for Safety and filters on errors to enahnce recoverability from them Package Smaller package trend (ex: 0.8 mm and lower pitch rate on BGA) and System in packages More reliable bonding (ex:opm) 22

23 Summary Architecture drivers: power, performance and safety/security Scalability of cores, simplification of IP Strong influence of safety for powertrain and chassis Extreme low power focus for body Architecture modularity Easier adaptation to new OEM domains architecture Sepratio of OEM and TIER1 software cost optimization De-centalization of application management Standard interfaces & robust interprocessor cominication Multicore architecture To manage power and performance To cost-efficiently enable Safety and Security Memories & IP Increased reliability and robustness to tougher enviroments (temperature, EMC, ESD) Lightweight Paradigm to sempify IP Smaller size for module (save power, reduce cost) 23

24 For Further Information System Architect Microcontroller System Group R&D Freescale Munich Office 24

25