1 / 167

Embedded Systems Software

Embedded Systems Software. Prof. Krithi Ramamritham Prof. Kavi Arya IIT Bombay. CEP - DEP 2003. Embedded Systems?. Embedded Systems. Single functional e.g. pager, mobile phone Tightly constrained cost, size, performance, power, etc. Reactive & real-time e.g. car’s cruise controller

sonel
Download Presentation

Embedded Systems Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Embedded Systems Software Prof. Krithi Ramamritham Prof. Kavi Arya IIT Bombay CEP - DEP 2003

  2. Embedded Systems?

  3. Embedded Systems • Single functional e.g. pager, mobile phone • Tightly constrained • cost, size, performance, power, etc. • Reactive & real-time • e.g. car’s cruise controller • delay in computation => failure of system

  4. Hardware is not the whole System !!! A Micro-Electronic System is the result of a projection of … • Architecture • Hardware • Software … distinguished by its gross Functional Behaviour ! • Software is an important part of the Product and must be part of the Design Process… or we are only designing a Component of the system.

  5. Why Is Embedded Software Not JustSoftware On Small Computers? • Embedded = Dedicated • Interaction with physical processes • sensors, actuators, processes • Critical properties are not all functional • real-time, fault recovery, power, security, robustness • Heterogeneity • hardware/software tradeoffs, mixed architectures • Concurrency • interaction with multiple processes • Reactivity • operating at the speed of the environment • These features look more like hardware! Source:Edward A. Lee, UC Berkeley SRC/ETAB Summer Study 2001

  6. What is Embedded SW? One definition: “Software that is directly in contact with, or significantly affected by, the hardware that it executes on, or can directly influence the behavior of that hardware.”

  7. What is Embedded SW? • What is it not? • Application software can be recompiled and executed on any number of hardware platforms so long as the basic services/libraries are provided. • It is divided by vertical market segments (application domains) • Well-established methodologies, architectures,… • HW platform independent, highly portable • Any SW that has no direct relationship with HW.

  8. Embedded System Challenges for HW Folks • PARADIGM CHANGE! • Designers main tasks convert from processor integration to performance analysis. Concentration on functional requirements instead of integration work • Concentration on architectural exploration (including performance analysis  Re-use and Platform-based design become key!  Early validation of system/solution correctness  Parallel hardware and software development  More effective use of previous work  Faster ways to build new elements of a solution  Ways to test more effectively, efficiently, quickly

  9. Software Guys can Learnfrom Hardware Experts! • Concurrency • the synchrony abstraction • event-driven modeling • Reusability • cell libraries • interface definition • Reliability • leveraging limited abstractions • leveraging verification • Heterogeneity • mixing synchronous and asynchronous designs • resource management Source:Edward A. Lee, UC Berkeley SRC/ETAB Summer Study 2001

  10. Trade-offs. Methodology ESW Architectural specifics • Portability • ESW itself is intended to provide portability for higher SW layers • (At least parts of) ESW is per definition not portable • Real-time • Restricted use of standardized Inter-process communication (IPC) mechanisms (CORBA,…) for performance reasons • Typically hard real-time requirements • RTOS dependency • Implementation of OS like services • Sometimes shielding of the RTOS to higher level SW layers • Direct dependency on RTOS implementation

  11. F2 FunctionalDesign F5 F1 F4 F3 (F2) ArchitecturalDesign Thread (F5) HW1 HW2 HW3 HW4 (F3) (F4) RTOS/Drivers Hardware Interface Functional Design & Mapping Source:Ian Phillips, ARM VSIA 2001

  12. Today’s Embedded World Never functional enough Always connected High Integration Chips (ASIC/SOC) Architectural diversity COTS & custom hardware EPROM/Flash/Rotating Media Software Intensive Web interfaces OOP Programming Model Standard applications The Embedded Market: Disruptive Change Source: Jim ReadyPresident / CEO MontaVista Software Traditional Embedded World Never small enough Never fast enough Headless/Character-based Standalone Boot & Run from ROM More Hardware than Software Low-Level Programming Model Application tied to hardware • Time to Market Pressures • Shortage of Embed. SW Engineers

  13. Plan • Embedded Systems • New Approaches to building ESW • New paradigms: Lava, Handel-C • Examples + “Engineering Returns to Software” • Build a RISC processor in 48hrs • Advantages of reconfigurable hardware. • Real-time support for ESW

  14. Motorola Software Survey Findings • Hardware design is a software task: IC designers write code (VHDL, Verilog, Scripting)! • We must become a software-intensive embedded system solutions company, focused on integrating our platforms into users’ products -in the future we’ll be neither a hardware nor a software company • Focus on developing systems capability, not just a software counterpart to our current hardware capability (though that’s needed too) • We should have software content from drivers to applications • The fundamental goal isn’t 70% margin on software products, it’s helping someone choose your total solution • Embedded systems platforms and solutions will be the key to market differentiation and profitable growth Source:Bob Altizer, BASYS VSIA 2001

  15. Common Design Metrics • NRE (Non-recurring engineering) cost • Unit cost • Size (bytes, gates) • Performance (execution time) • Power (more power=> more heat & less battery time) • Flexibility (ability to change functionality)

  16. Time to prototype • Time to market • Maintainability • Correctness • Safety (probability that system won’t cause harm)

  17. Peak revenue Peak revenue from delayed entry Revenues ($) On-time Market fall Market rise Delayed D W 2W On-time Delayed entry entry Time Time to Market Design Metric • Simplified revenue model • Product life = 2W, peak at W • Time of market entry defines a triangle, representing market penetration • Triangle area equals revenue • Loss • The difference between the on-time and delayed triangle areas • Avg. time to market today = 8 mth • 1 day delay may amount to $Ms • see Sony Playstation vs XBox Source: Embedded System Design: Frank Vahid/ Tony Vargis (John Wiley & Sons, Inc.2002)

  18. NRE and unit cost metrics • Compare technologies by costs -- best depends on quantity • Technology A: NRE=$2,000, unit=$100 • Technology B: NRE=$30,000, unit=$30 • Technology C: NRE=$100,000, unit=$2 • But, must also consider time-to-market Source: Embedded System Design: Frank Vahid/ Tony Vargis (John Wiley & Sons, Inc.2002)

  19. Area = 1/2 * base * height On-time = 1/2 * 2W * W Delayed = 1/2 * (W-D+W)*(W-D) Percentage revenue loss = (D(3W-D)/2W2)*100% Try some examples Peak revenue Peak revenue from delayed entry Revenues ($) On-time Market fall Market rise Delayed D W 2W On-time Delayed entry entry Time Losses due to delayed market entry • Lifetime 2W=52 wks, delay D=4 wks • (4*(3*26 –4)/2*26^2) = 22% • Lifetime 2W=52 wks, delay D=10 wks • (10*(3*26 –10)/2*26^2) = 50% • Delays are costly! Source: Embedded System Design: Frank Vahid/ Tony Vargis (John Wiley & Sons, Inc.2002)

  20. Trends • Moore’s Law • IC transistor capacity doubles every 18 mths • 1981: leading edge chip had 10k transistors • 2002: leading edge chip has 150M transistors • Designer productivity has improved due to better tools: • Compilation/Synthesis tools • Libraries/IP • Test/verification tools • Standards • Languages and frameworks (Handel-C, Lava, Esterel, …) • 1981: designer produced 100 transistors per month • 2002 designer produces 5000 transistors per month

  21. Our New Understanding • We have simultaneous optimisations of competing design metrics: speed, size, power, complexity, etc. • We need a “Renaissance Engineer” • with holistic view of design process and comfortable with technologies ranging from hardware, software to formal methods • Maturation of behavioral synthesis tools and other tools has enabled this kind of unified view of hardware/ software co-design. • Design efforts now focus at higher levels of abstraction => abstract specifications now refined into programs and then into gates and logic. • There is no fundamental difference of between what hardware and software can implement.

  22. Designer Productivity • “The Mythical Man Month” by Frederick Brooks ’75 • More designers on team => lower productivity because of increasing communication costs between groups • Consider 1M transistor project:- Say, a designer has productivity of 5000 transistor/mth- Each extra designer => decrease of 100 transistor/mth productivity in group due to comm. costs • 1 designer 1M/5000 = 200mth • 10 designer 1M/(10*4100) = 24.3mth • 25 designer 1M/(25*2600) = 15.3mth • 27 designer 1M/(27*2400) = 15.4mth • Need new design technology to shrink the design gap Source: Embedded System Design: Frank Vahid/ Tony Vargis (John Wiley & Sons, Inc.2002)

  23. Design Productivity Gap • Designer productivity has grown over the last decade • Rate of improvement has not kept pace with the chip-capacity growth • 1981: leading edge chip: • 100 designers * 100 trans/mth => 10k trans complexity • 2002: leading edge chip: • 30k designer mth * 5k trans/mth => 150M trans complexity • Designers at avg. of $10k pm=> cost of building leading edge chips has gone from $1M in 1981 to $300M in 2002 • Need paradigm shift to cope with the complexities of system design

  24. Plan • Embedded Systems • New Approaches to building ESW • New paradigms: Lava,Handel-C • Examples + “Engineering Returns to Software” • Build a RISC processor in 48hrs • Advantages of reconfigurable hardware. • Real-time support for ESW

  25. Lava • Not so much a hardware description language • More a style of circuit description • Emphasises connection patterns • Think of Lego

  26. Lava • Mary Sheeran, Koen Classen, & Satnam SinghChalmers University (Sweden) • Based on earlier work on MuFP to describe circuit functionality and layout in single language • Built using functional programming paradigm

  27. f g Behaviour and Structure f g f ->- g

  28. Lava Properties • Higher-order functions • Circuits are functions • May be passed as arguments to other functions. • => Easier to produce parameterized circuits than with VHDL. • Functions can return circuits as results • Circuit combinators take circuits as arguments, return circuits as results. • => Powerful glue for composing circuits to form larger systems. • Circuit combinators combine behavior + layout • Combinators lay out circuits in rows, columns, triangles, trees etc. • Performance of circuit • Improved by exploring the layout design space by experimenting with alternative layout combinators. • Examples of circuits produced: • High speed constant coefficient multipliers, finite impulse response filters (1D and 2D), adder tree networks and sorting butterfly networks.

  29. g f Parallel Connection Patterns f -|- g

  30. f f f f map f

  31. Four Sided Tiles

  32. Column

  33. fa Full Adder cout b sum a cin fa (cin, (a,b)) = (sum, cout) where part_sum = xor (a, b) sum = xorcy (part_sum, cin) cout = muxcy (part_sum, (a, cin))

  34. fa fa fa Generic Adder adder = col fa

  35. Top Level adder16Circuit = do a <- inputVec ”a” (bit_vector 15 downto 0) b <- inputVec ”b” (bit_vector 15 downto 0) (s, carry) <- adder4 (a, b) sum <- outputVec ”sum” s (bit_vector 16 downto 0) ? circuit2VHDL ”add16” adder16Circuit ? circuit2EDIF ”add16” adder16Circuit ? circuit2Verilog ”add16” adder16Circuit

  36. Xilinx FPGA Implementation • 16-bit implementation on a XCV300 FPGA • Vertical layout required to exploit fast carry chain • No need to specify coordinates in HDL code

  37. 16-bit Adder Layout Source: Mary Sheeran Nov.2002

  38. Four adder trees Source: Mary Sheeran Nov.2002

  39. No Layout Information Source: Mary Sheeran Nov.2002

  40. Plan • Embedded Systems • New Approaches to building ESW • New paradigms: Lava, Handel-C • Examples + “Engineering Returns to Software” • Build a RISC processor in 48hrs • Advantages of reconfigurable hardware. • Real-time support for ESW

  41. Handel-C • Programming language- enables compilation of programs into synchronous hardware • NOT Hardware Description Language- it’s a prog. language aimed at compiling high-level algorithms into gate-level hardware • Syntax (loosely) based on “C” • Handel-C is to hardware (gates) what “C” is to micro-assembly code

  42. Handel-C (cont.) • Inventor - Ian Page, Programming Research Group (Oxford University/UK) • Semantics based on Hoare’s Communication Seq. Processes (CSP) model & • Occam: transputer prog. language • Industry heavyweights using tools: Marconi, Ericcson, BAe, Creative Labs, etc.

  43. What this means • Hardware design produced is exactly the hardware specified in source program • No intermediate “interpreting” layer as in assembly language targeting general purpose microprocessor • Logic gates are assembly instructions of Handel-C system • Design/re-design/optimise at software level!!!

  44. What This Means • True parallelism • not time-shared (interpreted) parallelism of gen.purpose computers • PAR {a;b} • instructions executed in // at same instant of time by 2 sep. pcs of hw • Timing • branches that complete early forced to wait for slowest branch before continuing

  45. Comparison with “C” • Similar:- Programs inherently sequential- Similar control-flow constructs: if-then-else, switch, while, for, etc. • Dissimilar :- No malloc/ dynamic store allocation- No recursion (limited rec. in macros)- No nested procedures- No stdin/stdout - “Void main()”- variable width words- PAR, etc.

  46. Handel-C is based on • ANSI-standard C without external library-functions: • I/O functions: printf(), putc(), scanf(),... • File functions: fopen(), fclose(), fprintf(), ... • String-functions: length(), strcpy(), strcmp(),… • Math-functions: sin(), cos(), sqrt(),… • ...

  47. Supported declarationsstatements & instructions: • Main program structure • Variables • Arrays • Switch statement • FOR Loop • Comments • Constants • Scope & Variable sharing • Arithmetic, Relational, Relational Logic ops • Conditional Execution • While loop • Do … While Loop

  48. Channel Communication • link!v … link?v • channel input is form of assignment • Provides link between parallel (‘//’) branches • One // branch outputs data onto channel • Other // branch reads data from channel • => Synchronisation • data transfers only when both processes are ready

  49. Additional Features & Statements • Channel unsigned int 8 a; chan unsigned int 8 c; c ! 5; c ? A;

  50. Additional Features & Statements • Prialt prialt { case CommsStatement: Statement break; ... default: Statement break; }

More Related