1. High Performance Embedded Computing © 2007 Elsevier Chapter 1, part 2: Embedded Computing High Performance Embedded Computing Wayne Wolf

2. © 2006 Elsevier Topics Design methodologies. Methodologies and standards.

3. © 2006 Elsevier Design goals Functional requirements: input/output relations. Non-functional requirements: cost, performance, power, etc. Some project goals may be difficult to measure.

4. © 2006 Elsevier Aspects of performance Embedded system performance can be measured in many ways:  Average vs. worst/best-case.  Throughput vs. latency.  Peak vs. sustained.

5. © 2006 Elsevier Energy/power Energy consumption is important for battery life. Power consumption is important for heat generation or for generator-powered systems (vehicles).

6. © 2006 Elsevier Cost Manufacturing cost must be paid off across all the systems.  Hardest in small-volume applications. Manufacturing cost is incurred for each device. Lifetime costs include software and hardware maintenance and upgrades.

7. © 2006 Elsevier Other design attributes Design time must be reasonable. May need to finish by a certain date. System must be reliability; reliability requirements differ widely. Quality includes reliability and other aspects: usability, durability, etc.

8. © 2006 Elsevier Design methodology Design methodology: a procedure for creating an implementation from a set of requirements. Methodology is important in embedded computing:  Must design many different systems.  We may use same/similar components in many different designs.  Design time, results must be predictable.

9. © 2006 Elsevier Embedded system design challenges Design space is large and irregular. We don’t have synthesis tools for many steps. Can’t simulate everything. May need to build special-purpose simulators quickly. Often need to start software development before hardware is finished.

10. © 2006 Elsevier Design complexity vs. designer productivity

11. © 2006 Elsevier Basic design methodologies Figure out flow of decision-making. Determine when bottom-up information is generated. Determine when top-down decisions are made.

12. © 2006 Elsevier Waterfall and spiral models

13. © 2006 Elsevier Hardware design flow

14. © 2006 Elsevier Modeling in hardware Technology databases capture manufacturing process information. Cell libraries describe the cells used to compose designs. Logic synthesis systems use routability and timing models.

15. © 2006 Elsevier Hardware/software co-design flow

16. © 2006 Elsevier Platform-based design Platform includes hardware, supporting software. Two stage process:  Design the platform.  Use the platform. Platform can be reused to host many different systems.

17. © 2006 Elsevier Platform design Turn system requirements and software models into detailed requirements.  Use profiling and analysis tools to measure existing executable specifications. Explore the design space manually or automatically. Optimize the system architecture based on the results of simulation and other steps. Develop hardware abstraction layers and other software.

18. © 2006 Elsevier Programming platforms Programming environment must be customized to the platform:  Multiple CPUs.  Specialized memory.  Specialized I/O devices. Libraries are often used to glue together processors on platforms. Debugging environments are a particular challenge.

19. © 2006 Elsevier Standards-based design methodologies Standards enable large markets. Standards generally allow products to be differentiated.  Different implementations of operations, so long as I/O behavior is maintained.  User interface is often not standardized. Standard may dictate certain non-functional requirements (power consumption), implementation techniques.

20. © 2006 Elsevier Reference implementations Executable program that complies with the I/O behavior of the standard.  May be written in a variety of language. In some cases, the reference implementation is the most complete description of the standard. Reference implementation is often not well-suited to embedded system implementation:  Single process.  Infinite memory.  Non-real-time behavior.

21. © 2006 Elsevier Designing standards-based systems Design and implement system components that are not part of the standard. Perform platform-independent optimizations. Analyze optimized version of reference implementation. Design hardware platform. Optimize system software based on platform. Further optimize platform. Test for conformity to standard.

22. © 2006 Elsevier H/264/AVC Implements video coding for a wide range of applications:  Broadcast and videoconferencing.  Cell phone-sized screens to HDTV. Video codec reference implementation contains 120,000 lines of C code.

23. © 2006 Elsevier Design verification and validation Testing exercises an implementation by supplying inputs and testing outputs. Validation compares the implementation to a specification or requirements. Verification may be performed at any design stage; compares design at one level of abstraction to another.

24. © 2006 Elsevier Design verification techniques Simulation uses an executable model, relies on inputs. Formal methods generate a (possibly specialized) proof. Manual methods, such as design reviews, catch design errors informally.

25. © 2006 Elsevier A methodology of methodologies Embedded systems include both hardware and software.  HW, SW have their own design methodologies. Embedded system methodologies control the overall process, HW/SW integration, etc.  Must take into account the good and bad points of hardware and software design methodologies used.

26. © 2006 Elsevier Useful methodologies Software performance analysis. Architectural optimization. Hardware/software co-design. Network design. Software verification. Software tool generation.

27. © 2006 Elsevier Joint algorithm and architecture development Some algorithm design is necessarily performed before platform design. Algorithm development can be informed by platform architecture design.  Performance/power/cost trade-offs.  Design trends over several generations.