400 likes | 878 Views
ECOE 560 Design Methodologies and Tools for Software/Hardware Systems Spring 2006. Serdar Ta şı ran. Outline of today’s lecture. What is a software/hardware (embedded) system? Examples Characteristics The design problem Course outline Design automation methodologies and tools
E N D
ECOE 560Design Methodologies and Tools for Software/Hardware SystemsSpring 2006 Serdar Taşıran
Outline of today’s lecture • What is a software/hardware (embedded) system? • Examples • Characteristics • The design problem • Course outline • Design automation methodologies and tools • Levels of abstraction in design descriptions ECOE 560, Spring 2006
Definition • Embedded system: any device that includes a programmable computer but is not itself a general-purpose computer. • Take advantage of application characteristics to optimize the design: • don’t need all the general-purpose bells and whistles. ECOE 560, Spring 2006
Examples • Personal digital assistant (PDA). • Printer. • Cell phone. • Automobile: engine, brakes, dash, etc. • Television. • Household appliances. • PC keyboard (scans keys). ECOE 560, Spring 2006
Example: BMW 850i brake and stability control system • Anti-lock brake system (ABS): pumps brakes to reduce skidding. • Automatic stability control (ASC+T): controls engine to improve stability. • ABS and ASC+T communicate. • ABS was introduced first---needed to interface to existing ABS module. ECOE 560, Spring 2006
BMW 850i, cont’d. sensor sensor brake brake hydraulic pump ABS brake brake sensor sensor ECOE 560, Spring 2006
Characteristics of embedded systems • Sophisticated functionality. • Real-time operation. • Low manufacturing cost. • Low power. • Designed to tight deadlines by small teams. ECOE 560, Spring 2006
Functional complexity • Often have to run sophisticated algorithms or multiple algorithms. • Cell phone, laser printer. • Often provide sophisticated user interfaces. ECOE 560, Spring 2006
Real-time operation • Must finish operations by deadlines. • Hard real time: missing deadline causes failure. • Soft real time: missing deadline results in degraded performance. • Many systems are multi-rate: must handle operations at widely varying rates. ECOE 560, Spring 2006
Non-functional requirements • Many embedded systems are mass-market items that must have low manufacturing costs. • Limited memory, microprocessor power, etc. • Power consumption is critical in battery-powered devices. • Excessive power consumption increases system cost even in wall-powered devices. ECOE 560, Spring 2006
Design teams • Often designed by a small team of designers. • Often must meet tight deadlines. • 6 month market window is common. • Can’t miss back-to-school window for calculator. ECOE 560, Spring 2006
Example: HP DesignJet drafting plotter • Plots up to 36 inches wide at 300 DPI. • Combines a variety of tasks: • host communication; • graphics language interpretation; • rasterization; • device control. ECOE 560, Spring 2006
The plotting process HP-GL/2 PostScript rasterizer raster memory plotter controller ECOE 560, Spring 2006
Design considerations • Memory utilization is important. • 36 inches x large x 300 DPI x n bits/pixel is a lot of memory. • Requires clever algorithms to minimize raster memory requirements. • Requires real-time control. • Requires concurrency: read new data, rasterize, control print head. ECOE 560, Spring 2006
HP DesignJet hardware architecture 1 MB ROM i960KA adrs latch bus if 2 MB DRAM pen ctrl ASIC swath RAM EEPROM proc. support ASIC || if servo proc. (8052) carriage PC board RS- 422 DRAM ctrl front panel stepper motor ECOE 560, Spring 2006
Early architectural decisions • Chose Intel 80960KA as main processor. • Handled parsing, rasterization control, print engine control. • Multiplexed bus reduced pin count. • Could be upgraded to floating-point if necessary. • Used modular I/O to host system. • Did not use disk for local storage. ECOE 560, Spring 2006
System components • 2 MB RAM (SIMM sockets for more). • Three ASICs: • pen interface; • processor support; • carriage. • Servo processing performed by 8052 microcontroller. ECOE 560, Spring 2006
Rasterization • Plot is generated in swaths. • Separate swath memory. • Pixels are generated in row order by main processor. • Pixels are fed to pens in column order. • Pen interface ASIC transforms row order to column order. ECOE 560, Spring 2006
parsing and rasterization swath generation drawing Data flows 1 MB ROM i960KA adrs latch bus if 2 MB DRAM pen ctrl ASIC swath RAM EEPROM proc. support ASIC || if servo proc. (8052) carriage PC board RS- 422 DRAM ctrl front panel stepper motor ECOE 560, Spring 2006
Operations • Servo processor controls stepper motor. • Carriage processor must write, read pen alignment marks. • Processor support ASIC provides multiple functions: interrupt and mailbox communication. • Motion controller decodes position of print carriage and paper; watchdogs servo. ECOE 560, Spring 2006
Pen interface ASIC • Interfaces to i960 bus, swath memory, carriage ASIC. • Pen interface reads pixels from swath in predetermined pattern using pixel address generator. • Must support bidirectional printing since head prints both ways. ECOE 560, Spring 2006
Carriage ASIC • Interfaces to carriage processor bus, pen interface ASIC, servo controller. • Reads timing control registers using the CPU bus. • Delay registers add correction for pen alignment. ECOE 560, Spring 2006
Development process • Pixel shuffling algorithm for pen interface/carriage ASICs was prototyped in C. • Built emulators for ASICs to allow parallel development of i960 software and hardware. ECOE 560, Spring 2006
Software development environment • Plotter software could be run on Unix workstation or target platform. • Differed in I/O and print engine subsystems. • Print engine was emulated on host with X window interface showing swath state. • Used in-house RTOS. • HP-GL/2 parser was legacy code. ECOE 560, Spring 2006
Software development environment, cont’d. • Rewrote vector/raster converter from assembly language to C to port to i960. • Used gdb960 as monitor debugger on target system, communicating with host. • Front panel developed on PC, tested by user interface designers, marketing. • Paper loading designed by mechanical engineers. ECOE 560, Spring 2006
Outline of today’s lecture • What is a software/hardware (embedded) system? • Course outline • Design automation methodologies and tools • Levels of abstraction in design descriptions ECOE 560, Spring 2006
Course Outline • System design flow • Modeling, specifying, and representing systems: • Description languages for design specifications and implementations • Modeling formalisms: Models of computation and concurrency • Fundamentals:Boolean algebras, functions, relations. Propositional logic, first-order logic. Temporal logics. • Hardware implementation (component) technologies: CPUs, ASICs, FPGAs, DSPs, IP blocks, I/O components, networks, buses, on-chip communication networks, reconfigurable platforms. • Software implementation (component) technologies:Operating systems, real-time operating systems, inter-process communication, scheduling. • Analysis, verification, testing: Functionality.Design and implementation verification. Simulation, emulation, formal verification. • Analysis, verification, testing: Performance and timing.Timing analysis and verification of hardware and software. Performance evaluation and estimation. • Analysis, verification, testing: Power.Power analysis, optimization of hardware and software. Power minimization techniques. • System partitioning, architecture exploration. • Hardware synthesis. • Software synthesis • Interface design and synthesis ECOE 560, Spring 2006
Outline of today’s lecture • What is a software/hardware (embedded) system? • Course outline • Design automation methodologies and tools • Levels of abstraction in design descriptions ECOE 560, Spring 2006
Design methodologies • A procedure for designing a system. • Understanding your methodology helps you ensure you didn’t skip anything. • Compilers, software engineering tools, computer-aided design (CAD) tools, etc., can be used to: • help automate methodology steps; • keep track of the methodology itself. ECOE 560, Spring 2006
Design goals • Performance. • Overall speed, deadlines. • Functionality and user interface. • Manufacturing cost. • Power consumption. • Other requirements (physical size, etc.) ECOE 560, Spring 2006
Design Challenges:Increasing Device and Context Complexity • Exponential increase in device complexity—increasing with Moore’s law (or faster)! • System context in which devices are deployed (e.g. cellular radio) are increasing in complexity as well exponential increases in design productivity Complexity We have exponentially more components! ECOE 560, Spring 2006
Design Challenges: Deep Submicron Effects • Smaller geometries are causing a wide variety of effects that we have largely ignored in the past: • Cross-coupled capacitances • Signal integrity • Resistance • Inductance DSM Effects Design of each transistor is getting more difficult! ECOE 560, Spring 2006
Design Challenges: Heterogeneous Components Heterogeneity • Greater diversity of on-chip elements • Processors • Software • Memory • Analog More components doing different things! ECOE 560, Spring 2006
Design Challenges: Stronger Market Pressures • Decreasing design window • Less tolerance for design revisions Time-to-Money Exponentially more complex, greater design risk, greater variety, and a smaller design window ! ECOE 560, Spring 2006
Complexity Time-to-Money Heterogeneity DSM Effects A Quadruple-Whammy ECOE 560, Spring 2006
Processor Complexity Avg. Human IQ 180 160 140 120 100 80 50 Role of CAD: Helping humans cope Intelligence Quotient Transistors PPC603 10M Pentium 80486 Pentium Pro 1M PPC601 80386 68020 MIPS R4000 68040 68000 100K 8086 10K 4004 8080 1K 100 10 1 1975 1980 1985 1990 1995 ECOE 560, Spring 2006
Outline of today’s lecture • What is a software/hardware (embedded) system? • Course outline • Design automation methodologies and tools • Levels of abstraction in design descriptions ECOE 560, Spring 2006
Phases of a design flow requirements specification architecture component design system integration ECOE 560, Spring 2006
Top-down vs. bottom-up • Top-down design: • start from most abstract description; • work to most detailed. • Bottom-up design: • work from small components to big system. • Real design uses both techniques. ECOE 560, Spring 2006
Stepwise refinement • At each level of abstraction, we must: • analyze the design to determine characteristics of the current state of the design; • refine the design to add detail. • Design:specify and enter the design intent Verify: verify the correctness of design and implementation Implement:refine the design through all phases ECOE 560, Spring 2006