fundamentals of modern embedded systems
TRANSCRIPT
02223: Fundamentals of Modern Embedded Systems
Lecture 1: Introduc<on
Lecture 1/2
Lecture outline
• Course informa<on – Examina<on: project
• Modern embedded systems – Embedded systems design – Performance vs. predictability
• Examples – Automo<ve electronics – PlaySta<on 3, mobile phones – Mars Pathfinder
Lecture 1/3
Course informa<on
• Team (see contact info on CampusNet) – Jan Madsen, course leader – Paul Pop and Sven Karlsson, lecturers – Domi<an (Domi) Tamas-‐Selicean, Wajid Hassan Minhass teaching assistants
• Webpage – CampusNet
Lecture 1/4
Course informa<on, cont.
Literature
• Textbook: Scheduling in Real-‐Time Systems (full text available online)
• Selected chapters (full text available on CampusNet)
Lecture 1/5
Course informa<on, cont.
• Lectures – Language: English – 13 lectures
• Lecture notes: available on CampusNet as a PDF file the day before
• Examina<on: project, see CampusNet/Project – Report evalua<on and oral exam
• 7.5 ECTS points
Lecture 1/6
What is an embedded system?
• Defini<on – an embedded system special-‐purpose computer system, part of a larger system which it controls.
• Notes – A computer is used in such devices primarily as a means to simplify the system design and to provide flexibility.
– Oaen the user of the device is not even aware that a computer is present.
Product: Sonicare Plus toothbrush.
Microprocessor: 8-‐bit Zilog Z8.
Embedded systems example
Product: NASA's Mars Sojourner Rover.
Microprocessor: 8-‐bit Intel 80C85.
Embedded systems example, cont.
Product: Garmin nüvi
333 Mhz microprocessor
Embedded systems example, cont.
Product: iPod Touch
Microprocessor: 532MHz Samsung ARM
Embedded systems example, cont.
Product: RCA RC5400P DVD player.
Microprocessor: 32-‐bit RISC.
Embedded systems example, cont.
Product: Sony Aibo ERS-‐110 Robo<c Dog.
Microprocessor: 64-‐bit MIPS RISC.
Embedded systems example, cont.
Smart pills – 2nd genera<on
Flying micro-‐insects!
Do not have to be small …
Ship engine
Embedded systems are everywhere
o o o o o o
o o o o
o o o o o
o o o
o o
o
o
o o
o o
o
o o o
o o
Lecture 1/18
Characteris<cs of embedded systems
• Single-‐func<oned – Dedicated to perform a single func<on
• Complex func<onality – Oaen have to run sophis<cated algorithms or mul<ple algorithms.
• Cell phone, laser printer.
• Tightly-‐constrained – Low cost, low power, small, fast, etc.
• Reac<ve and real-‐<me – Con<nually reacts to changes in the system’s environment
– Must compute certain results in real-‐<me without delay
• Safety-‐cri<cal – Must not endanger human life and the environment
Some sta<s<cs
• More than humans on the planet, already – 40 billion of such devices by 2020
• 99% of the processors are used in embedded systems – 4 billion embedded processors were sold last year alone
• €71 billion global market in 2009, growth rates of 14% – Market size is about 100 <mes the desktop market
• Share of costs: – automo<ve (36%), industrial automa<on (22%), telecommunica<ons
(37%), consumer electronics (41%) and health/medical equipment (33%)
• Half a million more engineers needed, worldwide – expected to double over the next 6 years
Lecture 1/19
Level of dependency
Example area: automo<ve
Embedded systems: 90% future innova<ons 40% price
1970 1980 1990 2000
ACC Stop&Go BFD ALC KSG 42 voltage Internet Portal GPRS, UMTS Telema<cs Online Services BlueTooth Car Office Local Hazard Warning Integrated Safety System Steer/Brake-‐By-‐Wire I-‐Drive Lane Keeping Assist. Personaliza<on Soaware Update Force Feedback Pedal … Electronic Injec<ons
Check Control Speed Control Central Locking …
Naviga<on System CD-‐Changer ACC Adap<ve Cruise Control Airbags DSC Dynamic Stability Control Adap<ve Gear Control Xenon Light BMW Assist RDS/TMC Speech Recogni<on Emergency Call …
Electronic Gear Control Electronic Air Condi<on ASC An< Slip Control ABS Telephone Seat Hea<ng Control Autom. Mirror Dimming …
source: BMW
Distributed architecture
Evolu<on of Handsets and Technology
LCDs
Applica<on processor
Baseband ASIC
Mixed-‐Signal ASIC
Energy management ASIC
Posi<on sensors
512 MB DDR DRAM
512MB NAND FLASH
2MPix camera module
64MB NOR FLASH
64MB SDRAM
RF Bauery
White LED driver
Frame buffer ASIC
MMC
ARM9
UMA core
Keyboard
LED Flash
ARM9
UMA core
BT Module
SIM
IHF
Back-‐light LEDs
Block Diagram of State-‐of-‐the-‐art Smartphone
Charger
Tradi<onal embedded soaware development
• Design and build the target hardware
• Develop the soaware independently
• Integrate them and hope it works
Does not work for complex projects
System-‐level design (Y-‐chart)
Model of system implementation
System platform model
System-level design tasks
Analysis
Software synthesis
Hardware synthesis
Application model
Applica<on model
Architecture model
Graphical illustra<on of Moore’s law
1981 1984 1987 1990 1993 1996 1999 2002
Leading edge chip in 1981
10,000 transistors
Leading edge chip in 2002
150,000,000 transistors
• Something that doubles frequently grows more quickly than most people realize! – A 2002 chip could hold about 15,000 1981 chips inside itself
Design crisis
0.35µ 0.25µ 0.18µ 0.15µ 0.12µ 0.1µ
Log Scale
Gates/cm2
Moore’s Law (59% CAGR)
Widening Gaps Will Trigger Paradigm Shi6!
Design ProducHvity (20-‐25% CAGR)
SoLware ProducHvity (8-‐10% CAGR)
Technology (micron)
Design challenge – op<mizing design metrics
• Common metrics – Performance: the execu<on <me or throughput of the system
– Unit cost: the monetary cost of manufacturing each copy of the system, excluding NRE cost
– NRE cost (Non-‐Recurring Engineering cost): The one-‐<me monetary cost of designing the system
– Size: the physical space required by the system
– Power: the amount of power consumed by the system
– Flexibility: the ability to change the func<onality of the system without incurring heavy NRE cost
Design challenge – op<mizing design metrics
• Common metrics (con<nued) – Time-‐to-‐prototype: the <me needed to build a working version of the system
– Time-‐to-‐market: the <me required to develop a system to the point that it can be released and sold to customers
– Maintainability: the ability to modify the system aaer its ini<al release
– Correctness, safety, many more
The performance design metric
• Widely-‐used measure of system, widely-‐abused – Clock frequency, instruc<ons per second – not good measures
• Latency (response <me) – Time between task start and end – e.g., Digital cameras A and B process images in 0.25 seconds
• Throughput – Tasks per second, e.g. Camera A processes 4 images per second – Throughput can be more than latency seems to imply due to concurrency, e.g.
Camera B may process 8 images per second (by capturing a new image while previous image is being stored).
• Speedup of B over S = B’s performance / A’s performance – Throughput speedup = 8/4 = 2
Time-‐to-‐market: a demanding design metric
• Time required to develop a product to the point it can be sold to customers
• Market window – Period during which the
product would have highest sales
• Average <me-‐to-‐market constraint is about 8 months
• Delays can be costly
Revenues ($)
Time (months)
Power design metric: trends
Hot Plate
Nuclear Reactor
386 486
PenHum
PenHum Pro
PenHum 2
PenHum 3
PenHum 4 (Presco[) PenHum 4
Lecture 1/34
Project: Why?
• The course will focus on the analysis, simulaHon and design of embedded systems.
• Goal – Understand and apply simula<on/analysis/design
techniques for embedded applica<ons.
– How: implement a soaware tool that can simulate/analyze/design an embedded system.
• Details – see these slides and “project.pdf” on CampusNet/Project
Lecture 1/35
Project: What?
• Soaware tool: – Implementa<on of simula<on, analysis and/or design
techniques for embedded systems
A1: Very Simple Simulator Simulate the running of an embedded applica<on on a single processor system, using preemp<ve fixed-‐priority scheduling
A2: Response-‐Time Analysis Determine the worst-‐case response <mes for the embedded system simulated in A1
Lecture 1/36
Project: How?
• Soaware tool – Input
• Models for the applica<on and hardware architecture (Lecture 2) – Worst-‐case execu<on <me of each process (Lectures 3)
– Timing constraints (deadlines)
• Scheduling policy – Fixed-‐priority preemp<ve scheduling (Lectures 4−6)
– Another scheduling policy (Lectures 7−12 and bibliography)
– Output • Is the applica<on mee<ng all the deadlines?
– Performance numbers: e.g., worst-‐case response <mes
Lecture 1/37
Project: Deliverables
• Source code with comments – Programming language: any language is fine
• Sugges<on: Java, using the Jung graph library and GraphML for capturing the models: hup://jung.sourceforge.net/
• See the examples on CampusNet/Project
• Report – Document the design and implementa<on – Describe the results obtained
– See the documents on CampusNet/Project • “soaware_development_projects.pdf” and
“Systema<c Soaware Test.pdf”
Lecture 1/38
Project, cont.
• Milestones – Early September: Group registra<on – Late October: Advanced topic selec<on
• Decide on the “advanced technique” to be implemented – Present your advanced topic and get feedback
– End of October: Project report draa • Upload draa to CampusNet
– It should contain a descrip<on of the advanced topic
– Beginning of December: Final report submission • Upload final report to CampusNet
Preliminary lecture plan
L1 Introduc<on (Paul Pop, Sven Karlsson) L2 Performance analysis (Jan Madsen) Lab: SimpleScalar L3 Worst-‐case execu<on <me analysis (Jan Madsen) Lab: aIT L4 Scheduling for embedded systems (Paul Pop) Lab: Project L5 Schedulability analysis (I) (Paul Pop) Lab: TIMES L6 Schedulability analysis (II) (Paul Pop) Lab: TIMES
L7 Handling shared resources (Paul Pop) Realis<c exercise L8 Handling dependencies (Paul Pop) Lab: MAST L9 Parallel programming (Sven Karlsson) Lab: OpenMP L10 Aspects of parallel programming (Sven Karlsson) Lab: CELL simul. L11 Hybrid scheduling (Paul Pop) Exercise L12 Mul<-‐core systems (Paul Pop/Jan Madsen) Lab: MAST L13 Outlook