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

o o

oo oo

o o

o oo

oo oo

oo

o

oo

o

o

oo

oo

o

o o

o

oo

Embedded systems are everywhere

Our daily lives depend on embedded systems

Product: Sonicare Plus toothbrush.

Microprocessor: 8-bit Zilog Z8.

From your bathroom...

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 ElectronicsLe

vel o

f dep

ende

ncy

Embedded systems:90% future innovations40% price

1970 1980 1990 2000

ACC Stop&GoBFDALCKSG42 voltageInternet PortalGPRS, UMTSTelematicsOnline ServicesBlueToothCar OfficeLocal Hazard WarningIntegrated Safety

SystemSteer/Brake-By-WireI-DriveLane Keeping Assist.PersonalizationSoftware UpdateForce Feedback Pedal…

Electronic InjectionsCheck ControlSpeed ControlCentral Locking…

Navigation SystemCD-ChangerACC Adaptive Cruise

ControlAirbagsDSC Dynamic Stability

ControlAdaptive Gear ControlXenon LightBMW AssistRDS/TMCSpeech RecognitionEmergency Call…

Electronic Gear ControlElectronic Air ConditionASC Anti Slip ControlABSTelephoneSeat Heating ControlAutom. Mirror Dimming…

sour

ce: B

MW

Automotive architecture example

Evolution of handsets and technology

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

ARM9

UMA core

BT Module

SIM

IHF

Back-light LEDs

Charger

Smartphone architecture example

Architectures: Networked embedded systems

Distributedacross

networks

...

...Several functions

per processor

DistributedfunctionalityDistributedfunctionality

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

1981 1984 1987 1990 1993 1996 1999 2002

Leading edgechip in 1981

10,000transistors

Leading edgechip in 2002

150,000,000transistors

Graphical illustration of Moore’s law

• 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.

Test tubes

Robotics

Microfluidics

AutomationIntegration

Miniaturization

AutomationIntegration

Miniaturization

AutomationIntegration

Miniaturization

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)

0.35µ 0.25µ 0.18µ 0.15µ 0.12µ 0.1µ

Lo

g S

ca

leGates/cm2

Moore’s Law

Widening Gap

Design Productivity

Software Productivity

Technology (micron)

Design crisis

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

abst

ract

Transistor ModelCapacity Load

1970’s

cluster

abst

ract

Gate Level ModelCapacity Load

1980’s

RTL

cluster

abst

ract

SDFWire Load

1990’s

IP Blocks

cluster

abst

ract

IP Block PerformanceInter IP Communication Performance Models

RTLClusters

SWModels

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 DevicesInput devicesHardware Platform

I OHardware

Software

Network

Software Platform

Application SoftwarePlatform API

Model of system implementation

System platform model

System-leveldesign tasks

Evaluation

Softwaresynthesis

Hardware

synthesis

Application model

Application model

Architecture model

System-level design

Constructive vs.improvement Analysis vs.

simulation

Typical design tasks: Mapping and schedulingGiven

– 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 m2m3 m4

P3

N1

N2

Bus

Schedule

table

Deadline

P1

P4

P2 P3

m1 m2

m3 m4

N1 N2

Operation Area (cells) Time (s) Mixing 2x2 6 Mixing 2x3 5 Mixing 2x4 4

Dilution 2x2 6 Dilution 2x3 5 Dilution 2x4 3 Storage 1x1 –

Biochips design tasks

Scheduling

Binding

Placement

Allocation

S1

S2

S3 B

R1

R2

W

Store

Mixer1

Mixer2

Dil

uter

Detector

Mixer1

Mixer2

Diluter

Store

Detector

O7

O9

O3

O11

O10 O4

1 2

3

4

5 6

7

10

8

9

In S1 In R 1

Mix

Detect

In S2 In B

DiluteIn R 2

Mix

Detect

Source

Sink

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

36

1. CANBUS Introduction What is CANBUS? Who uses CANBUS? CANBUS history CANBUS timeline

2. CANBUS Characteristics OSI Model Physical Layer Transmission Characteristics

3. Message Oriented Communication4. Message Format5. Bus Arbitration

Presentation Goals

37

CANBUS or CAN bus – Controller Area Network bus

An automotive serial bus system developed to satisfythe 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

What is CANBUS?

38

• Designed specifically for automotive applications• Today - industrial automation / medical equipment

Who uses CANBUS?

39

Automotive Medical / Industrial0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

CANBUS Market Distribution

Markets

CANBUS History

40

• 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

41

• 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.

• CAN is a closed network– – no need for security, sessions or logins.– - no user interface requirements.

• Physical and Data Link layers in silicon.

CANBUS and the OSI Model

42

CANBUS Physical Layer

43

Conventional multi-wire looms CAN bus network

Physical medium – two wires terminated at both ends by resistors. Differential signal - better noise immunity. Benefits:

Reduced weight, Reduced cost Fewer wires = Increased reliability

vs.

http://canbuskit.com/what.php

Transmission Characteristics

44

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

45

• 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

46

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

Example of Message Transaction

47

Bus Arbitration

48

• 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.

Bus Arbitration

49

• 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.

• 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

Summary

50

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

Bus arbitration

51

Bus Arbitration Flowchart

52

ExerciseTest 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 ECUGroup 2 Narcis & Niroy: Engine ECUGroup 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 bothGroup 2 Program a system that sends temeratures on request and alarm for overheatingGroup 3 Program a system that sends tyre pressure on request and alarm for very low pressure