Large to small… Systems Embedded Electronics Large to small… Systems By Peter Faber, April/May 2015

Embedded Systems Invisible computers, inside most of the devices we use, from a music player, a mobile phone, to cars, trains, medical equipment, and so on. an embedded system special-purpose computer system, part of a larger system which it controls More than humans on the planet, already 40 billion of such devices by 2020 99% of processors used in embedded systems 4 billion embedded processors sold last year €71 billion global market in 2009, growth of 14% Market size is about 100 times the desktop market

Embedded systems are everywhere o Our daily lives depend on embedded systems

From your bathroom... Product: Sonicare Plus toothbrush. Microprocessor: 8-bit Zilog Z8.

To Mars... Product: NASA's Mars Sojourner Rover. Microprocessor: 8-bit Intel 80C85.

Big...

And small...

Characteristics of embedded systems Single-functioned Dedicated to perform a single function Complex functionality Often have to run sophisticated algorithms or multiple algorithms. Cell phone, laser printer. Tightly-constrained Low cost, low power, small, fast, etc. Reactive and real-time Continually reacts to changes in the system’s environment Must compute certain results in real-time without delay Safety-critical Must not endanger human life and the environment

Automotive Electronics Level of dependency Embedded systems: 90% future innovations 40% price 1970 1980 1990 2000 ACC Stop&Go BFD ALC KSG 42 voltage Internet Portal GPRS, UMTS Telematics Online Services BlueTooth Car Office Local Hazard Warning Integrated Safety System Steer/Brake-By-Wire I-Drive Lane Keeping Assist. Personalization Software Update Force Feedback Pedal… Electronic Injections Check Control Speed Control Central Locking … Navigation System CD-Changer ACC Adaptive Cruise Control Airbags DSC Dynamic Stability Control Adaptive Gear Control Xenon Light BMW Assist RDS/TMC Speech Recognition Emergency Call… Electronic Gear Control Electronic Air Condition ASC Anti Slip Control ABS Telephone Seat Heating Control Autom. Mirror Dimming Automotive industry 40% of the vehicle’s costs and 90% of new innovation related to software or electronics 100-fold increase of code lines in two decades Software for monitoring and controlling car state, media players, database programs etc. source: BMW

Automotive architecture example

Evolution of handsets and technology

Smartphone architecture example White LED driver LCDs Application processor Baseband ASIC Mixed-Signal ASIC Energy management ASIC Position sensors 512 MB DDR DRAM 512MB NAND FLASH 2MPix camera module 64MB NOR FLASH 64MB SDRAM RF Battery Frame buffer ASIC MMC ARM9 UMA core Keyboard LED Flash BT Module SIM IHF Back-light LEDs Charger

Architectures: Networked embedded systems Distributed functionality ... Distributed across networks Several functions per processor ...

Application areas: critical vs. best-effort Critical (e.g., avionics) Based on worst-case assumptions Static reservation of resources Schedulability analysis and static scheduling Simple execution platforms Leads to overdesign (underutilization) Best effort (e.g., multimedia, networks) Based on average-case Dynamic reservation of resources Sophisticated architectures Adaptive scheduling mechanisms Leads to temporary unavailability Bridging the gap: partitioned architectures

Graphical illustration of Moore’s law 1981 1984 1987 1990 1993 1996 1999 2002 Leading edge chip in 1981 10,000 transistors chip in 2002 150,000,000 Something that doubles frequently grows more quickly than most people realize! A 2002 chip could hold about 15,000 1981 chips inside itself

More Moore vs. More than Moore

Tubes to Chips: Integrated Circuits Driven by Information Processing needs IBM 701 calculator (1952) IBM Power 5 IC (2004) Slide soruce: Krish Chakrabarty, Duke University

Tubes to Chips: Biochips Driven by biomolecular analysis needs Test tube analysis Agilent DNA analysis Lab on a Chip (1997) Slide soruce: Krish Chakrabarty, Duke University

Tubes to Chips: Biochips, cont. Automation Integration Miniaturization Test tubes Automation Integration Miniaturization Robotics Automation Integration Miniaturization Microfluidics Slide soruce: Krish Chakrabarty, Duke University

Biochip Architecture Slide soruce: Krish Chakrabarty, Duke University

Embedded systems design problem Find an implementation that can perform the computation such that the requirements are satisfied. Embedded systems perform computations (software) that are subject to physical constraints (hardware) Reaction to a physical environment: deadline, throughput, jitter Execution on a physical platform: processor speed, power, reliability The need for an embedded systems design discipline Computer science separates computation from physical constraints Computer engineering ignores computation

Traditional embedded systems design Design and build the target hardware Develop the software independently Integrate them and hope it works Does not work for complex systems !!!!

Embedded software: size and deployment

Embedded software: complexity growth

Increasing complexity (telecom example)

Design crisis 0.35µ 0.25µ 0.18µ 0.15µ 0.12µ 0.1µ Log Scale Gates/cm2 Moore’s Law Widening Gap Design Productivity Software Productivity Technology (micron)

We need a better design methodology Design methodology: the process of creating a system Goal: optimize competing design metrics Time-to-market Design cost Manufacturing cost Quality, etc. Design flow: sequence of steps in a design methodology. May be partially or fully automated. Use tools to transform, verify design. Design flow is one component of design methodology. Methodology also includes management, organization, etc.

Abstraction and clustering Transistor Model Capacity Load 1970’s cluster Gate Level Model 1980’s RTL SDF Wire Load 1990’s IP Blocks IP Block Performance Inter IP Communication Performance Models Clusters SW Models Year 2000 +

Abstraction and clustering: Platforms The “PC platform” makes development easier x86 instruction-set architecture fully specified set of buses and a specified set of I/O devices Similar platform definitions for specific embedded systems application areas Output Devices Input devices Hardware Platform I O Hardware Software Network Software Platform Application Software Platform API

System-level design tasks Model of system implementation Application model System platform model Application model Architecture model System-level design tasks Constructive vs. improvement Model of system implementation Evaluation Analysis vs. simulation Software synthesis Hardware synthesis

Typical design tasks: Mapping and scheduling Given Application: set of interacting processes Platform: set of nodes Timing constraints: deadlines Determine Mapping of processes and messages Schedule tables for processes and messages Such that the timing constraints are satisfied S2 S1 P1 P4 P2 m1 m2 m3 m4 P3 N1 N2 Bus Schedule table Deadline

Biochips design tasks Allocation Binding Placement Scheduling

Design-space exploration

Safety-Critical Systems Safety is a property of a system that will not endanger human life or the environment. A safety-related system is one by which the safety of the equipment or plant is ensured. Safety-critical system is: Safety-related system, or High-integrity system Our daily lives depend on embedded systems

Introduction to CANBUS

Presentation Goals CANBUS Introduction CANBUS Characteristics What is CANBUS? Who uses CANBUS? CANBUS history CANBUS timeline CANBUS Characteristics OSI Model Physical Layer Transmission Characteristics Message Oriented Communication Message Format Bus Arbitration

What is CANBUS? CANBUS or CAN bus – Controller Area Network bus An automotive serial bus system developed to satisfy the following requirements: Network multiple microcontrollers with 1 pair of wires. Allow microcontrollers communicate with each other. High speed, real-time communication. Provide noise immunity in an electrically noisy environment. Low cost

Who uses CANBUS? Designed specifically for automotive applications Today - industrial automation / medical equipment

CANBUS History First idea - The idea of CAN was first conceived by engineers at Robert Bosch Gmbh in Germany in the early 1980s. Early focus - develop a communication system between a number of ECUs (electronic control units). New standard - none of the communication protocols at that time met the specific requirements for speed and reliability so the engineers developed their own standard.

CANBUS Timeline 1983 : First CANBUS project at Bosch 1986 : CAN protocol introduced 1987 : First CAN controller chips sold 1991 : CAN 2.0A specification published 1992 : Mercedes-Benz used CAN network 1993 : ISO 11898 standard 1995 : ISO 11898 amendment Present : The majority of vehicles use CAN bus.

CANBUS and the OSI Model CAN is a closed network – no need for security, sessions or logins. - no user interface requirements. Physical and Data Link layers in silicon.

Conventional multi-wire looms CANBUS Physical Layer Physical medium – two wires terminated at both ends by resistors. Differential signal - better noise immunity. Benefits: Reduced weight, Reduced cost Fewer wires = Increased reliability Conventional multi-wire looms CAN bus network vs. http://canbuskit.com/what.php

Transmission Characteristics Up to 1 Mbit/sec. Common baud rates: 1 MHz, 500 KHz and 125 KHz All nodes – same baud rate Max length:120’ to 15000’ (rate dependent) © esd electronics, Inc. • 525 Bernardston Road • Greenfield, MA 01301

Message Oriented Transmission Protocol Each node – receiver & transmitter A sender of information transmits to all devices on the bus All nodes read message, then decide if it is relevant to them All nodes verify reception was error-free All nodes acknowledge reception CAN bus © 2005 Microchip Technology Incorporated. All Rights Reserved.

Message Format Each message has an ID, Data and overhead. Data –8 bytes max Overhead – start, end, CRC, ACK

Example of Message Transaction

Bus Arbitration Arbitration – needed when multiple nodes try to transmit at the same time Only one transmitter is allowed to transmit at a time. A node waits for bus to become idle Nodes with more important messages continue transmitting CAN bus © 2005 Microchip Technology Incorporated. All Rights Reserved.

Lower value = More important Bus Arbitration Message importance is encoded in message ID. Lower value = More important As a node transmits each bit, it verifies that it sees the same bit value on the bus that it transmitted. A “0” on the bus wins over a “1” on the bus. Losing node stops transmitting, winner continues.

Summary CAN bus – Controller Area Network bus Primarily used for building ECU networks in automotive applications. Two wires OSI - Physical and Data link layers Differential signal - noise immunity 1Mbit/s, 120’ Messages contain up to 8 bytes of data

Bus arbitration A “0” (low voltage) on the bus by 1 node wins over a “1” (high voltage) on the bus.

Bus Arbitration Flowchart

Exercise Test Your system is working up against the main ECU (my CAN system). You’ll now figure out and program the following: Each group will program their own ECU, to be placed somewhere in ”the car”. Group 1 Marius & Jonathan: Dashboard ECU Group 2 Narcis & Niroy: Engine ECU Group 3 Martin & Georgi: Tyre System ECU Group 1 Program a system that asks the engine for temperature and the Tyre System for pressure And accepts emergency messages from both Group 2 Program a system that sends temeratures on request and alarm for overheating Group 3 Program a system that sends tyre pressure on request and alarm for very low pressure