Verification of High Performance Embedded Systems Sisira K. Amarasinghe, Ph.D.
Verification of High Performance Embedded Systems Sisira K. Amarasinghe, Ph.D. Outline Embedded Systems High Performance Embedded Systems Verification and Validation Conventional Verification of Embedded Systems Verification of Complex Systems Conclusion Questions and Answers 2 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation, consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 3 of Introduction to Embedded Systems (2/4) Designed for some specific tasks Subjected to real time performance constraints that must be met Feature tightly integrated combinations of hardware and software 4 of Introduction to Embedded Systems (3/4) Typical embedded software components: Embedded Application Code Device Drivers A Real-Time Operating System (RTOS) Hardware abstraction layer(s) System initialization routines 5 of User Interface Analog i/p Digital i/p Analog Front End Digital i/p Ports User Interface Modules interrupts D/A, Isolation.. Digital o/p Ports Support: Timers Watchdog INPUTS CPU Data Bus Analog o/p Digital o/p OUTPUTS Comms: ASC, SSC, USB, IIC, IrDA, etc. Address Bus Data Memory Program Memory Links to Other Systems 6 of Outline Embedded Systems High Performance Embedded Systems Verification and Validation Conventional Verification of Embedded Systems Verification of Complex Systems Conclusion Questions and Answers 7 of High Performance Embedded Systems (1/10) Massive computational resources with requirements of – Small size – Low Weight – Very low power consumption. Need to employ innovative, advanced system architectures 8 of High Performance Embedded Systems (2/10) Architectures typically feature – Multiple processor cores – Tiered memory structures with multi-level memory caching – Multi-layer bus structures. – Super-pipelining and/or super-scaling 9 of High Performance Embedded Systems (3/10) The current state-of-the-art: Multiple computational and dataprocessing engines, memory, and peripherals, all constructed on a single silicon chip called a System-on-Chip (SoC). Designs to feature multiple generalpurpose central processing unit (CPU) cores as well as special-purpose digital signal processor (DSP) cores 10 of High Performance Embedded Systems (4/10) 32-Bit MCU RISC Strengths Register Based Architecture Reduced Instruction Set Instruction Pipeline C/C++ language support Memory Protection 32-Bit RISC Core 16-Bit FP DSP Core MCU Strengths Tricore Real Time Control High System Integration Range of On-Chip Peripherals Dedicated Bit Manipulation unit TriCore 32-Bit MCUDSP Unified MCU-DSP DSP Strengths Zero Overhead Loop Dedicated Hardware Multipliers Powerful Multi-Operation Instructions Addressing Modes Data Formats 11 of High Performance Embedded Systems (5/10) Embedded designs to include multiple general-purpose central processing unit (CPU) cores as well as special-purpose digital signal processor (DSP) cores Firmware Peripherals Core 1 Core 2 Memory Core 3 12 of High Performance Embedded Systems (6/10) Multilayer Bus Structures – CPU and DSP cores can have separate buses for control, instructions, and data, – DMA buses along with one or more dedicated peripheral buses. – Both the CPUs and DSPs can have tightly-coupled memory buses, external memory buses, and shared memory buses. 13 of High Performance Embedded Systems (7/10) Increasing software content – The software content of embedded systems is increasing at a phenomenal rate – software development and test often dominate the costs, timelines, and risks associated with today's embedded system designs. 14 of High Performance Embedded Systems (8/10) 15 of High Performance Embedded Systems (9/10) Decreasing design cycles – Market windows are continually narrowing – Competition gets more and more aggressive – Consumer electronics markets are extremely sensitive to time-to-market pressures 16 of High Performance Embedded Systems (10/10) 17 of Outline Embedded Systems High Performance Embedded Systems Verification and Validation Conventional Verification of Embedded Systems Verification of Complex Systems Conclusion Questions and Answers 18 of Verification and Validation (1/7) What is Verification and Validation? – Verification Verification confirms that work products properly reflect the requirements specified for them. In other words, verification ensures that ‘the product has been built right’. 19 of Verification and Validation (2/7) – Validation Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that ‘you built the right thing’”. 20 of Verification and Validation (3/7) Why Verification and Validation? – Business considerations •Legal •Refutation •Warranty / Recall – Regulatory issues •FDA •FAA •DoD 21 of Verification and Validation (4/7) – Safety considerations •Life sciences •Mission critical •Automotive examples: –Drive by wire »Electronic throttle control »Electronic steering –ABS –Airbag Systems 22 of Verification and Validation (5/7) 23 of Verification and Validation (6/7) Abstraction Levels of Design Under Verification Behavioral Model – Example: c <= a * b – May not include timing information – Verification examines the basic operation and interactions among the systems’ components RTL (Register-Transfer-Level) Model – VHDL/Verilog commonly used to model RTL – Accurate cycle-level information (no propagation delays) – Verification of exact cycle behavior Gate-Level Model – Specifies each individual logic element and their interconnections – Verification at this level is time-consuming but necessary for clock boundaries and reset conditions 24 of Verification and Validation (7/7) Importance of Verification in Early Design Stages Revenue loss due to delay in Time-To-Market Behavioral RTL Gate Level Transistor Ease of verification Remove as many bugs as possible in early designs stages Source: Verification Methodology Manual, 2000 - TransEDA 25 of Outline Embedded Systems High Performance Embedded Systems Verification and Validation Conventional Verification of Embedded Systems Verification of Complex Systems Conclusion Questions and Answers 26 of Conventional Verification of Embedded Systems (1/13) Determine the overall system architecture Design System Hardware Construct hardware prototype Install and test OS and/or middleware Develop, port, integrate, and debug embedded software 27 of Conventional Verification of Embedded Systems (2/13) Conventional verification drawback (mainly due to shorter design cycles) – SoC to be fabricated before developing the software – Having to wait for the implementationlevel representation of the design (specified RTL) to become available before developing the embedded software. 28 of Conventional Verification of Embedded Systems (3/13) Physical Prototypes as primary verification mechanism – Typically involves a circuit board and the SoC in the form of working silicon. •The hardware portion of the design is now almost 100 percent tied down •Not much useful in the context of exploring and evaluating alternative architectures 29 of Conventional Verification of Embedded Systems (4/13) – Important hardware/software tradeoffs can’t be made before the design partitioning is locked down and the chips are manufactured •System design must be largely based on experience and intuition, as opposed to hard data. •Unacceptable in today's complex algorithms, multi-core systems, tiered memory systems, and multi-layered bus structures. 30 of Conventional Verification of Embedded Systems (5/13) Hardware acceleration and emulation as verification mechanism – These typically involve arrays of fieldprogrammable gate arrays (FPGAs) or processors. – These solutions accept RTL representations of the design and translate them into an equivalent suitable for hardware acceleration. – The verification can get very costly 31 of Conventional Verification of Embedded Systems (6/13) – Issues in multi-processor designs – Emulators also have problems with limited visibility into the design – Software development cannot commence until a long way into the design cycle. (The hardware design is largely established limitations with regard to exploring and evaluating alternative architectures) 32 of Conventional Verification of Embedded Systems (7/13) RTL-based simulation as verification mechanism – An RTL simulation solution requires RTL representations of the hardware Delays in meaningful software development until the RTL becomes available – It simply isn't possible to use software simulation to determine how well the architecture performs on real software workloads 33 of Conventional Verification of Embedded Systems (8/13) – A software simulation running on a on very high-end (and correspondingly expensive) machine would hardly achieve equivalent simulation speeds of more than a few Hz • That is, a few cycles of embedded system clock for each second in real time • Detailed simulations can be performed on only small portions of the software. 34 of Conventional Verification of Embedded Systems (9/13) ISS-based simulation as verification mechanism Verify and debug chips using software models that can execute the same binary code as the actual processors Limitations: – Only processor cores can be modeled – Accuracy is compromised for high performance verification (typically not cycle accurate) – Lack of synchronization support for multi-processor based systems 35 of Outline Embedded Systems High Performance Embedded Systems Verification and Validation Conventional Verification of Embedded Systems Verification of Complex Systems Conclusion Questions and Answers 36 of Verification of Complex Systems (1/15) System-On-Chip (SoC) designs increasingly become the driving force of a number of modern electronics systems A number of key technologies integrate together in forming the highly complex embedded platform Verification need to account for integration of a number of different IPs into new designs, the coupling of embedded software into designs, and the verification flow from core to the design, etc. 37 of Verification of Complex Systems (2/15) IP Core Verification and System Level Verification both need to be addressed adequately On top of structural complexities, further bottlenecks are introduced by: – Time to market pressures – Increasing software content – Other stringent design constraints such as size, weight, low power levels, etc. 38 of Verification of Complex Systems (3/15) The system level design strategies should be considered together with the complex task of verification Hardware , first, then software, is no longer a viable theme Appropriate verification strategies need to be employed from the outset to minimize downstream defects including SoC re-spins Concurrent hardware and software development would mandatory. 39 of Verification of Complex Systems (4/15) SoC architects to employ a broad system level design strategy that will allow: – Explore and evaluate system level architectural choices – Concurrent hardware-software design – Easily evaluate and integrate a number of different technologies – Adequate verification at every level of the design cycle 40 of Verification of Complex Systems (5/15) – Carry out an architecture level power analysis – Drive requirements for executable specifications – Provide visibility into designs – Easily handle regression testing How do we achieve all this with such complexity? 41 of Verification of Complex Systems (6/15) The answer to all above is to employ a Unified System Model without committing to any pre-conceived hardware / software partitioning. This will be a type of electronic systems level (ESL) prototype The form of these models can be anywhere from a cycle-accurate RTL model and to a time-efficient ISS model, or a hybrid 42 of Verification of Complex Systems (7/15) Source: “Mixed-Abstraction Virtual System Prototypes Close SOC Design Gaps”, Carbon Design Systems, Inc. 43 of Verification of Complex Systems (8/15) Running Speed 100MHz Ideal Verification 10MHz Solution Make it faster Real Silicon Rapid Prototype 1MHz 100KHz Make it cheaper HW Emulator 10KHz 1KHz HW Accelerator 100Hz SW Simulator 10Hz Investment 44 of Verification of Complex Systems (9/15) The basis for a unified system model is Transaction Level Modeling (TLM). Transactions Basic representation for exchange of information between two blocks Improve efficiency and performance of verification by raising the level of abstractions from the signal level Can be as simple as a single data write operation or linked together to form a complex IP packet transfer 45 of Verification of Complex Systems (10/15) Transactions: Source: Cadence white paper, “The Unified Verification Methodology” 46 of Verification of Complex Systems (11/15) Transactor provides a level of abstraction between the pins of the model and the test code – Encapsulation: Test code does not need knowledge about the bus protocols – Abstraction: Allows test to be written in an abstract fashion that specifies the required transactions, instead of the operation execution details – Re-use: Transactor provides a standard set of routines that the test can call – Modularity: Verification environment can be built from a set of parts Stimulus Generation: Transactions Transactor Write Operation Test Code Write (Addr, data) Test Interface Read Operation Data = Read (Addr) Bus Driver Processor Bus DESIGN UNDER VERIFICATION Others Operations 47 of Verification of Complex Systems (12/15) Support functional design and verification at various abstraction levels Advantages – Enhance reusability in the test-benches – Improve debugging and coverage analysis C to HDL HW part model SW part model Synthesis C HDL EDIF Transactor Transactor Transactor Transactor Transactor C ISS Cross-compiler Processor Transaction Level Models (TLM) Source: Chong-Min Kyung, “Current Status and Challenges of SoC Verification for Embedded Systems Market”, IEEE International 48 of SOC Conference, 2003 Verification of Complex Systems (13/15) Unified System Model: Functional Prototype Unambiguous executable specification Golden top-level verification environment and integration vehicle Reference for defining transaction coverage requirements Model for performing architectural trade-offs Early handoff vehicle to system development teams Fast executable model for early embedded software development Source: Cadence white paper, “The Unified Verification Methodology” 49 of Verification of Complex Systems (14/15) Functional Level to Implementation Level Prototype Source: Cadence white paper, “The Unified Verification Methodology” 50 of Verification of Complex Systems (15/15) Unified System Model with the highest desirable abstraction is created early in the design process by the SoC verification team working closely with the architects A test suite is included with the Functional Prototype Each subsystem has its own TLM (Transaction Level Model) defined at the SoC partition Individual subsystem teams proceed to develop the implementation level of the subsystem The test suite is run on the FVP as each subsystem implementation is integrated into the FVP The process of integration is facilitated by transactors, which translate information between the transaction and signal level Once all the transaction-level models are replaced, the implementation level prototype is complete 51 of Outline Embedded Systems High Performance Embedded Systems Verification and Validation Conventional Verification of Embedded Systems Verification of Complex Systems Conclusion Questions and Answers 52 of Conclusion Embedded systems tend to contain tens of processor cores with multi-layered busses and bus-bridges. Hardware and software development a mandatory design methodology. Existing embedded system verification strategies do not offer enough sophistication for today's complex systems. 53 of Conclusion TLM based Unified System Models provide a means to carry out design and verification hand in hand while promoting hardware / software codevelopment. Source: DSP Design Line 54 of End of Presentation Thank you! Any Questions ? 55 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation, consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 56 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation, consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 57 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 58 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation, consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 59 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation, consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 60 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation, consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 61 of Introduction to Embedded Systems (1/4) An application specific electronic sub- system which is completely encapsulated by the main system it belongs to. The main systems can range from household appliances, home automation, consumer electronics, ATMs, network routers, automobiles, aircrafts, etc. 62 of High Performance Embedded Systems (3/10) The current state-of-the-art: Multiple computational and dataprocessing engines, memory, and peripherals, all constructed on a single silicon chip called a System-on-Chip (SoC). Designs to feature multiple generalpurpose central processing unit (CPU) cores as well as special-purpose digital signal processor (DSP) cores 63 of Conventional Verification of Embedded Systems (7/13) RTL-based simulation as verification mechanism Testbench DUV a = 1; #20 b = 1; $display (“status is = %d”,c); ... Source: Chong-Min Kyung, “Current Status and Challenges of SoC Verification for Embedded Systems Market”, IEEE International SOC Conference, 2003 64 of Conventional Verification of Embedded Systems (5/13) Hardware acceleration and emulation as verification mechanism – These typically involve arrays of fieldprogrammable gate arrays (FPGAs) or processors. Simulation environment Hardware Accelerator Testbench Module 0 Module 1 Module 2 Module 2 is synthesized & compiled into FPGAs Source: Chong-Min Kyung, “Current Status and Challenges of SoC Verification for Embedded Systems Market”, IEEE International SOC Conference, 2003 65 of Conventional Verification of Embedded Systems (5/13) Hardware acceleration and emulation as verification mechanism Emulation hardware with multiple FPGAs Logic design Design mapping & FPGA 0 > & FPGA 1 Crossbar (Switch) + FPGA 2 FPGA 3 Source: Chong-Min Kyung, “Current Status and Challenges of SoC Verification for Embedded Systems Market”, IEEE International SOC Conference, 2003 External pins 66 of Verification of Complex Systems (4/15) Specification Meet Specifications? SoC architects employ a broad system Behavioralto Model DESIGN VERIFICATION level design strategy that Implement Behavior?will allow: RTL Model – Explore and evaluate system level architectural choices Equivalent? Gate-Level Model – Concurrent hardware-software design – Easily evaluate Equivalent? and integrate a number of Transistor-Level Model different technologies – Adequate verification at every level of the design cycle 67 of Verification of Complex Systems (1/15) System-On-Chip (SoC) 68 of Brief Introduction Graduated with First Class Honors in Electronic and Telecommunication Eng (1986) Won the Presidential Scholarship (Sri Lanka) and a Fulbright Fellowship (USEF), and undertook graduate studies leading to M.Sc. (Microprocessor Eng and Digital Electronics) (1989), Ph.D. (Information Systems Engineering) (1992), at U. of Manchester Inst of Sc and Tech, UK. Employed as a faculty member (Information Engineering) at Nanyang Technological University, Singapore (1992-1999) Served the industry in USA at senior technical and management positions (1999 – To date) 69 of Center for High Performance Embedded Systems (CHiPES), NTU, Singapore CHiPES was established by the Nanyang Technological University in April 1998 to promote research and development in embedded systems engineering using state-of-the-art VLSI CAD tools and technology. 70 Selected Research Projects FPGA Based High Performance Architecture for Move Generation in Computer Chess 71 Selected Research Projects Multiple Sequence Families with Efficient Hardware Architecture for use in Spread Spectrum Watermarking for Multimedia Game Tree Search on a Massively Parallel SIMD Machine Massively Parallel Implementation of a Pattern Based Evaluation Function for Computer Chess 72 Technology Comparison Application Slide - 73 Specific Time to Market: Design Cycle ASIC design cycle is longer compared to FPGA because more time has to be spent on verification, timing closure and prototyping. Application Slide - 74 Specific Development Costs: Process Geometry ASIC NRE cost is rapidly increasing with process improvements while NRE is almost non-existent in FPGAs. However, ASIC remains the preferred option only for very high volume productions. Application Slide - 75 Specific Time to Market: A Hybrid Approach FPGAs can be used for a quick entry into the market (FPGA-to-ASIC conversion can be done later) – The convergence of the ASIC and FPGA design methodology makes it easy to adopt an ‘FPGA first ASIC later’ approach. – RTL coding should be done with future FPGA-to-ASIC transition in mind. Application Slide - 76 Specific Upgradability With FPGAs, it is possible to extend product life by adding new features – Quick response to changing standards – Apply bug fixes by just downloading a new configuration file to the device. Application Slide - 77 Specific Application Slide - 78 Specific Typical ASIC Flow Application Slide - 79 Specific Convergence of ASIC & FPGA Design Flows Application Slide - 80 Specific Design Cycle Time Source: NEC Application Slide - 82 Specific
© Copyright 2024