CENG328_LN03.pdf

Lecture 03: Design of Embedded Systems Dr. Abdulmalik Alwarafy Spring 2024 CENG 328: Introduction to Embedded Systems Outline • Importance of Design Methodology • Design Goals • Design Process • Requirements • Specification • Architecture Design • System Integration • Types of Design Methodolog...

Lecture 03: Design of Embedded Systems Dr. Abdulmalik Alwarafy Spring 2024 CENG 328: Introduction to Embedded Systems Outline • Importance of Design Methodology • Design Goals • Design Process • Requirements • Specification • Architecture Design • System Integration • Types of Design Methodology Section 1.2 3 Embedded systems Overview 4 Embedded Systems product development process BOM: bill of materials PCB: Printed Circuit Board 5 Importance of a Design Methodology • Design methodology is a procedure for designing system. • Helps in tracking design objectives and keeps a scorecard on design to ensure nothing is skipped. • Compilers, software engineering tools, computeraided design (CAD) tools, etc., can be used to: • help automate methodology steps; • keep track of methodology itself. • Team communication & coordination • A design methodology makes it easier for members of design team to communicate. 6 Image Source: www.storyboardthat.com we should put clear design methodology to reflect required design, then coordinate among all parties during project development Design Goals • Functionality and user interface • Performance • Overall speed, delay, accuracy • Manufacturing cost • Power consumption • Other requirements (physical size, weight, time to market, quality, etc.) 8 GPS Navigation Unit Source: https://www.pcmag.com/ Embedded System Design Process • 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. • At each level of abstraction, we must: • analyze design to determine how to meet requirements; • refine design to add detail. n 10 Requirements • Plain language description of what the user wants and expects to get. • Functional requirements • Output as a function of input. • Non-functional requirements • Performance: time required to compute output; • Cost: includes manufacturing and nonrecurring engineering (NRE) costs • Physical size and weight • Power consumption, reliability; etc. 11 Requirements Analysis • Requirements analysis • Check for requirements consistency; • Sample requirements form name purpose inputs outputs functions performance manufacturing cost power physical size/weight Types of data: Analog? Digital? Data Characteristics: Periodically arriving data? Occasional user inputs? #bits per data element? Types of I/O devices: Buttons? Analog/Digital Conv.? Video displays? Communication : SPI, I2C, UART, WIFI .. 12 Example: GPS Moving Map Requirements User’s current position • Moving map obtains position from GPS, paints map from local database. • Functionality: For automotive use. Show major roads and landmarks. • User interface: At least 400 x 600 pixel screen. Three buttons max. Pop-up menu. • Performance: Map should scroll smoothly. No more than 1 sec power-up. Lock onto GPS within 15 seconds. • Cost: $120 street price = approx. $40 cost of goods sold. • Physical size/weight: Should fit in hand. • Power consumption: Should run for 8 hours on four AA batteries. User’s lat/long position 13 GPS Moving Map Requirements Form name GPS moving map purpose consumer-grade moving map for driving inputs power button, two control buttons outputs back-lit LCD 400 X 600 functions manufacturing cost Use 5-receiver GPS; three resolutions; always displays current lat/lon updates screen within 0.25 sec of movement $40 cost-of-goods-sold power 100 mW physical size/weight no more than 2" X 6", 12 oz. performance 14 Specification • A formal more precise description of system that reflects customer’s requirements in a way that can be clearly followed during design. • should not imply particular architecture; • provides input to architecture design process. • A contract between customer & architects • Clarifies design objectives & prevents faulty assumptions • Should be: • Understandable: so it can be verified against requirements • Unambiguous: so designers are clear about what to build 15 Specification..cont • Unclear specifications can result in design problems. • If the behavior of some feature in particular situation is unclear from specification, designer may implement wrong functionality. • If global characteristics of specification are wrong or incomplete, overall system architecture derived from specification may be inadequate to meet needs of implementation. 16 GPS Specification • Should include several components: • Data received from GPS satellite constellation; • Map data; • User interface; • Operations required to satisfy user requests; • Background operations needed to keep system running. • Unified Modeling Language (UML): is a language used for describing specifications. 17 Architecture Design • Purpose of architecture is to describe how system implements required functions • Plan for overall structure of system • Architecture design uses Block Diagrams, which define: Hardware architecture, Software architecture • Must satisfy functional & non-functional requirements 18 GPS Moving Map Block Diagram • block diagram shows major operations & data flows among them GPS receiver Search Engine database renderer user interface display General Architecture 19 GPS Moving Map Hardware Architecture display frame buffer CPU GPS receiver memory panel I/O 20 GPS Moving Map Software Architecture • Timer used to control when we read buttons on user interface & render data onto screen position pixels database search renderer user interface timer 21 Designing Hardware and Software Components • What major components needed for satisfying specification? • Hardware components: CPUs, peripherals, FPGAs, boards, etc. • Software components: major programs & their operations. • Component design builds system components according to architecture & specification. • Some components are ready-made, some are modified from existing designs, others designed from scratch. 22 Designing Hardware and Software Components • Ready-made, standard components: • CPU, memory, GPS receiver • Software library, topographic data databases • Custom components: • PCB, FPGA • Custom software modules FPGA: Field Programmable Gate Array PCB: Printed Circuit Board 23 System Integration • Putting system components together • Many bugs appear only at this stage • Have a plan for integrating components to uncover bugs quickly, test as much functionality as early as possible • Bug discovery • Building system in phases • Testing • Debugging facilities for embedded systems are limited than what we find on desktop systems; always a challenge. • Inserting appropriate debugging facilities during design can help ease system integration problems. 24 Design Methodologies • Waterfall model • Spiral model • Successive refinement model • V model • Hardware/software design methodology •… 25 Design Methodologies The spiral model of software design The waterfall model of software development A successive refinement development model. 26 Design Methodologies..cont 27 Summary • Discussed the importance of Design Methodology • Discussed Design Goals and Process • Types of Design Methodologies • Discussed the importance of Requirements and specification • Discussed Architecture Design and System Integration 29