1. Introduction Special-purpose processors. Embedded systems. FPGAs.

2. Course overview: Syllabus Schedule Project Student info (collect)

3. Goal: quickly and efficiently produce special-purpose processors / software for specific applications Hardware basis in this course: FPGAs (PLAs) IN OUT BUS CLOCK RESET MEM IN LOGIC (LOOK-UP TABLE) MEMORY (1-BIT) CARRY IN LOCAL BUS GLOBAL BUS CARRY OUT BUS MEM OUT FPGA (EX) SINGLE FPGA CELL RAM BLOCK

4. DESIGNING AN FPGA-BASED CIRCUIT / PROCESSOR: USE HIGH-LEVEL ABSTRACTION USE HARDWARE DESCRIPTION LANGUAGES USE AUTOMATED TOOLS TO PRODUCE LAYOUT MAY FINE-TUNE DESIGN DETAILS DESIGN APPLICATION-SPECIFIC PROCESSOR / SOFTWARE

5. Final product: “embedded system” Reference: http://en.wikipedia.org/wiki/Embedded_system

6. Embedded system implemented in FPGA: Special-purpose “computer” designed to be IN device it controls user is provided with a processor with basic functionality processor can be programmed in software Additional features can be added using the FPGA resources to customize the design for a specific intended use Processor core may be “hard” (built-in as part of the chip) or “soft” (using some of available FPGA resources. Ex: Altera Nios II processor) Processor may have options—e.g., number of registers, floating point units Specialized CAD tools allow addition of additional functionality Hardware / software codesign now becomes a possibility

7. The basic codesign process—as presented at: http://ls12-www.cs.uni-dortmund.de/~niemann/codesign/codesign.html Strengths: Flexibility, Design Productivity; Weaknesses: Performance, Resource Usage Strengths: Flexibility, Design Productivity;

8. Typical embedded system properties: human interface--may be as simple as a flashing light or as complicated as real-time robotic vision. diagnostic port may be used for diagnosing the system that is being controlled -- not just for diagnosing the computer. Special-purpose field programmable (FPGA), application specific (ASIC), or even non-digital hardware may be used to increase performance or safety. Software often has a fixed function, and is specific to the application. Good embedded system reference: http://www.ece.cmu.edu/~koopman/iccd96/iccd96.html#introduction Much of the following information is taken from this site

9. Examples:

10. Design issues: System may need to be real-time / reactive (does not mean “fast” necessarily) Usually must be small and not weigh much Must be safe and reliable Must meet budget constraints (cost) May need to work in harsh environmental conditions (e.g., in an automobile)

11. System requirements Focus is on end-use capability, not on CPU performance, memory size, etc. System software must be safe and reliable Power usage should be low, depending on applications System typically controls a physical system—sensors / actuators

12. Embedded system lifecycle / requirements: Components—same component may work in several different systems—this can lower cost Safety certification—must often meet rigorous requirements Recertification—if system is modified Logistics / repair—accessibility is important Upgrades—need to be handled efficiently Component availability—may be long-term needs

13. “business model”: What are design / production costs? What is the life-cycle? Are there “product families”?

14. Design culture: Computer/ VLSI—simulate,simulate,simulate Mechanical/sensors—build, build, build Differing world views need to be reconciled