Fundamentals of Modern Embedded Systems
Upcoming SlideShare
Loading in...5

Fundamentals of Modern Embedded Systems






Total Views
Views on SlideShare
Embed Views



5 Embeds 67 44 11 9 2 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Fundamentals of Modern Embedded Systems Fundamentals of Modern Embedded Systems Presentation Transcript

  • 02223:  Fundamentals  of     Modern  Embedded  Systems   Lecture  1:   Introduc<on  
  • 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/2  
  • 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/3  
  • Course  informa<on,  cont.   Literature   •  Textbook:   Scheduling  in  Real-­‐Time  Systems   (full  text  available  online)   •  Selected  chapters   (full  text  available  on  CampusNet)   Lecture  1/4  
  • 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/5  
  • 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.     Lecture  1/6  
  • Embedded  systems  example   Product:  Sonicare  Plus  toothbrush.   Microprocessor:  8-­‐bit  Zilog  Z8.  
  • Embedded  systems  example,  cont.   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.  
  • 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  
  • 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   Lecture  1/18  
  • 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  
  • Example  area:     automo<ve   Embedded  systems:   90%  future  innova<ons   ACC  Stop&Go   BFD   40%  price   ALC   KSG   42  voltage   Internet  Portal   GPRS,  UMTS   Telema<cs   Naviga<on  System   Online  Services   CD-­‐Changer   BlueTooth   Level  of  dependency   ACC  Adap<ve  Cruise   Car  Office   Control   Local  Hazard  Warning   Airbags   Integrated  Safety  System   DSC  Dynamic  Stability   Steer/Brake-­‐By-­‐Wire   Control   I-­‐Drive   Electronic  Gear  Control   Adap<ve  Gear  Control   Lane  Keeping  Assist.   Electronic  Air  Condi<on   Xenon  Light   Personaliza<on   ASC  An<  Slip  Control   BMW  Assist   Soaware  Update   ABS   RDS/TMC   Force  Feedback  Pedal   Electronic  Injec<ons   …   Telephone   Speech  Recogni<on   source:  BMW   Check  Control   Seat  Hea<ng  Control   Emergency  Call   Speed  Control   …   Autom.  Mirror  Dimming   Central  Locking   …   …   1970   1980   1990   2000  
  • Distributed  architecture  
  • Evolu<on  of  Handsets  and  Technology  
  • Block  Diagram  of  State-­‐of-­‐the-­‐art  Smartphone   Bauery   RF   Baseband  ASIC   Charger     Energy   management   64MB   ASIC   NOR   FLASH   White  LED   ARM9   driver   64MB   Back-­‐light   SDRAM   UMA  core   Mixed-­‐ LEDs   Signal  ASIC   SIM   2MPix   camera   module   IHF   BT   LED  Flash   Module   Keyboard   Applica<on   512MB   processor   MM NAND   C   FLASH   ARM9   512  MB   DDR   Frame   DRAM   UMA  core   buffer  ASIC   Posi<on   sensors   LCDs  
  • 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)   Application System platform model model Applica<on    model   System-level Architecture    model   design tasks Model of system Analysis implementation Software Hardware synthesis synthesis
  • Graphical  illustra<on  of  Moore’s  law   1981 1984 1987 1990 1993 1996 1999 2002 10,000 150,000,000 transistors transistors Leading edge Leading edge chip in 1981 chip in 2002 •  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   Gates/cm2   Moore’s  Law   (59%  CAGR)   Widening  Gaps   Log  Scale   Will  Trigger     Paradigm  Shi6!   Design  ProducHvity   (20-­‐25%  CAGR)   SoLware  ProducHvity   (8-­‐10%  CAGR)   0.35µ   0.25µ   0.18µ   0.15µ   0.12µ   0.1µ   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   Revenues ($) –  Period  during  which  the   product  would  have  highest   sales   •  Average  <me-­‐to-­‐market   Time (months) constraint  is  about  8  months   •  Delays  can  be  costly  
  • Power  design  metric:  trends   Nuclear  Reactor   PenHum  4  (Presco[)   PenHum  4   Hot  Plate   PenHum  3   PenHum  2   PenHum  Pro   PenHum   486   386  
  • 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/34  
  • 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/35  
  • 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/36  
  • 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://   •  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/37  
  • 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   Lecture  1/38  
  • 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