SoC Verification Strategies for Embedded Systems Design

Transcription

1 SOC Design Conference SoC Verification Strategies for Embedded Systems Design November 5-6, 2003/ Seoul Chong-Min Kyung, KAIST 1

2 Various Embedded Mobile Systems Data Processing Consumer Desktop PC DVC Audio Media Center Notebook PC Smart Phone PDA DSC MP3 Player DVD DTV Game Console Internet Cellular Phone Credit Card Car Navigation Communication Bluetooth Telematics Automotive & etc. 2

3 Difficulties in Embedded Systems Design (What s special in ES design?) Real operating environment of ES is difficult to reproduce. -> In-system verification is necessary. Total design flow of ES until the implementation is long and complex. -> Verification must be started early. Design turn-around time must be short as the life-time of ES itself is quite short. -> Short verification cycle 3

4 Three Most Important Issues in Verification 1. Verify Right : Always make sure you have correct specifications to start with. (Frequent interaction with SPECIFIER, customer, marketing, etc.) In-System Verification Check Properties in Formal Techniques. 2. Verify Early System-level, Heterogeneous Models, SW-HW 3. Verify Appropriately HW-SW Co-simulation 4. Verify Fast Hardware Acceleration, Emulation 4

5 Strongly Required Features of Verification Accommodate Multiple Levels of Design Representation Exploit Hardware, Software and Interfacing mechanisms as Verification Tools 5

6 Virtual Chip : Verify Early, In-System Virtual Chip: Making Functional Models Work on Real Target System [DAC98] Simulating ISS of a Processor Chip along with real target environment Chip Model;ISS Chip Socket Target board Host computer as Virtual Chip cable Pin Signal Generator with Buffers 6

7 Without CPU PC running ISS Picture taken in 1993 or

8 Reducing TTM using Virtual Chip Conventional design flow H/W System Application S/W Architectural model Board design design RTL model Gate-level model idle idle H/W Emulation H/W prototype (H/W emulation) Verification w/ H/W Virtual Chip design flow; EARLY,IN-SYSTEM H/W System Application S/W Architectural model Board design design RTL model Gate-level model H/W prototype (Virtual Chip) H/W Emulation Verification w/ H/W Design time is drastically reduced 8

9 Microprocessor Design Verification Methodology CPU Model more refined model C Language HDL Instruction Behavior In C (Polaris) Microarchitecture in C RTL Verilog Gate-Level Verilog Virtual Chip FlexPC MCV PLI Real Mother-board H/W Virtual PC in C (VPC) Target Environment MCV : Microcode Verifier PLI : Programming Language Interface 9

10 HK386 (1995) Design Specification Instruction level, Pin-to-Pin compatible with i386 Operation speed : 40 MHz 0.8 m DLM CMOS ASIC Test Programs MS DOS 6.0, Windows 3.1, Office 4.0 CAD tools, games, etc.. MS Win. 3.1 MS Office MaxPlus II 10

11 What about Emulation? Swallowed a lot of Money Required a separate, air-conditioned room Needed a lot of time for Compile Needed an expensive slowed-down PC ($20,000 for 500kHz clocking) However worked at the last minute Finding bugs is not easy 11

12 x86 Emulation Configuration Probe Module 500kHz Slowed-Down PC Target Interface Board Hardware Emulator 12

13 Instructions (thousand) Booting Windows 20M instructions on Marcia Simulation debugs, Emulation approves. setup version update 1 HDL saver Attached HDL Simulation Time (weeks) version update 2 version update 3 Windows Hardware Emulation DOS 13

14 Agenda Verify Early and Altogether (In-System) Why Verification? Verification Alternatives Verification with Progressive Refinement SoC Verification Concluding Remarks 14

15 Trend of Verification Effort in the Design Verification portion of design increases to anywhere from 50 to 80% of total development effort for the design K gates Code Verify (30 ~ 40%) Synthesis P&R M SoC Code Verify (50 ~ 80%) Synthesis P&R Verification methodology manual, TransEDA 15

16 Percentage of Total Flaws About 50% of flaws are functional flaws. Need verification method to fix logical & functional flaws Race 5% Clocking 5% Yield 7% Power 4% Other 9% Logical/ Functional 45% Noise 12% Slow Path 13% From Mentor presentation material,

17 Another recent independent study showed that more than half of all chips require one or more re-spins, and that functional errors were found in 74% of these re-spins. With increasing chip complexity, this situation could worsen. Who can afford that with >= 1M Dollar NRE cost? 17

18 Bug Fixing Cost in Time Cost of fixing a bug/problem increases as design progresses. Need verification method at early design stage Cost of Fixing a Problem Behavioral Design RTL Design Gate Level Device Design Production Verification methodology manual, 2000 TransEDA 18

19 Simulation performance Verification complexity Verification Performance Gap; more serious than the design productivity gap Growing gap between the demand for verification and the simulation technology offered by the various options. Verification Performance Gap SOC Complex ASIC Small ASIC Medium ASIC Design complexity System-on-a-chip verification, 2001 P.Rashinkar 19

20 Completion Metrics; How do we know when the verification is done? Emotionally, or Intuitively; Out of money? Exhausted? Competition s product is there. Software people are happy with your hardware. There have been no bugs reported for two weeks. More rigorous criteria; All tests passed Test Plan Coverage Functional Coverage Code Coverage Bug Rates have flattened toward bottom. 20

21 Verification Challenges Specification and/or Operating Environment is Incomplete/Undetermined. (Just like last-minute ECO!) Cannot avoid using Yesterday s tool for Today s Design. Design productivity grows faster than Verification productivity. (Verification productivity Gap) Besides Functional Verification, Estimation on Performance, Power Consumption becomes crucial issues in SoC design. 21

22 Agenda Verify early and in-system Why Verification? Verification Alternatives Simulation Hardware-accelerated simulation Emulation Prototyping Formal verification Semi-Formal (Dynamic Formal) verification Verification with Progressive Refinement SoC Verification Concluding Remarks 22

23 Overview of Verification Methodologies Basic verification tool Simulation Hardware Accelerated Simulation Semi-formal Verification Emulation Formal Verification Prototyping 23

24 Software Simulation Pros The design size is limited only by the computing resource. Simulation can be started as soon as the RTL description is finished. Set-up cost is minimal. Cons Slow (~100 cycles/sec) ; Speed gap between the speed of software simulation and real silicon widens. (Simulation speed = size of the circuit simulated / speed of the simulation engine) The designer does not exactly know how much percentage of the design have been tested. 24

25 Hardware-Accelerated Simulation Simulation performance is improved by moving the time-consuming part of the design to hardware. Usually, the software simulation communicates with FPGA-based hardware accelerator. Simulation environment Testbench Hardware Accelerator Module 0 Module 2 Module 1 Module 2 is synthesized & compiled into FPGAs 25

26 Hardware-Accelerated Simulation Pros Fast (100K cycles/sec) Cheaper than hardware emulation Debugging is easier as the circuit structure is unchanged. Not an Overhead : Deployed as a step stone in the gradual refinement Cons (Obstacles to overcome) Set-up time overhead to map RTL design into the hardware can be substantial. SW-HW communication speed can degrade the performance. Debugging of signals within the hardware can be difficult. 26

27 Emulation Imitating the function of another system to achieve the same results as the imitated system. Usually, the emulation hardware comprises an array of FPGA s (or special-type processors) and interconnection scheme among them. About 1000 times faster than simulation. Prototyping Simulation Hardware Accelerated Simulation Emulation 27

28 Emulation Pros Cons Fast (500K cycles/sec) Verification on real target system. Setup time overhead to map RTL design into hardware is very high. Many FPGA s + resources for debugging high cost Circuit partitioning algorithm and interconnection architecture limit the usable gate count. 28

29 Emulation Challenges Efficient interconnection architecture and Hardware Mapping efficiency for Speed and Cost RTL debugging facility with reasonable amount of resource Efficient partitioning algorithm for any given interconnection architecture Reducing development time (to take advantage of more recent FPGA s) 29

30 Prototyping Special (more dedicated and customized) hardware architecture made to fit a specific application. Prototyping Simulation Hardware Accelerated Simulation Emulation 30

31 Prototyping Pros Cons 10X higher clocking than emulation Components as well as the wiring can be customized. Can be carried and dispatched for demo or customer evaluation Not flexible for design change (Even a small change requires a new PCB.) 31

32 Overview of Verification Methodologies Formal verification Application of logical reasoning to the development of digital system Both design and its specification are described by a language in which semantics are based on mathematical rigor. Semi-formal verification Combination of simulation and formal verification. Formal verification cannot fully cover large designs, and simulation can come to aid in verifying the large design. Simulation Semi-formal Verification Formal Verification More complete verification 32

33 Formal Verification Classes Pros Cons Model Checking : verifies that the design satisfies properties specified using temporal logic Equivalence Checking Symbolic Simulation Theorem Proving Assures 100% coverage. Run fast. Works only for small-size finite state systems due to memory explosion. (so far, <500 flip-flops) Uncomfortable, i.e., need to learn temporal logic for property description in Model Checking 33

34 Efforts by Formal People to reduce the Complexity Reachability analysis Design state abstraction Design decomposition 34

35 Semi-Formal Verification - Assertion Assertion-based verification (ABV) Assertion is a statement on the intended behavior of a design. The purpose of assertion is to ensure consistency between the designer s intention and the implementation. 35

36 Number of bugs found Semi-Formal Verification - Assertion Simulation Quality of assertion-based verification Simulation with assertions Efficiency of assertion Formal verification Simulation Setup testbench Describe assertions Time, Effort By IBM in Computer-Aided Verification

37 Semi-Formal Verification - Coverage Coverage-directed verification Increase the probability of bug detection by checking the quality of stimulus Used as a guide for the generation of input stimulus Test Plan (Coverage Definition) Directives Random Test Generator Test Vectors Coverage Reports Coverage analysis Simulation 37

38 Semi-Formal Verification Pros Cons Designer can measure the coverage of the test environment as the formal properties are checked during simulation. Simulation speed is degraded as the properties are checked during simulation. Challenges Guiding the direction of test vectors to increase the coverage of the design. Development of more efficient coverage metric to represent the behavior of the design. 38

39 Speed Comparison Speed (Cycles/sec, log scale) 10MHz 1~10MHz 1MHz 500KHz 100 khz 100kHz 10 khz 100Hz 50-70Hz 0 khz Software Simulation Hardware- Accelerated Simulation (from Quickturn/Dynalith Presentation) Hardware emulation (from Quickturn presentation) Prototyping Semi-formal (Assertionbased verification) 39

40 Verification Time vs. Coverage (not to exact scale): Which best fits your application? Coverage Emulation /Simulation Acceleration Semi-formal Prototyping Simulation Simulation setup Semi-formal setup Emulation /SA setup Prototyping setup Verification Time 40

41 Agenda Verify early and in-system Why Verification? Verification Alternatives Verification with Progressive Refinement Flexible SoC verification environment Debugging features Cycle vs. transaction mode verification SoC Verification Concluding Remarks 41

42 Criteria for Good SoC Verification Environment Support various abstraction levels Support heterogeneous design languages Trade-off between verification speed and debugging features Co-work with existing tools Progressive refinement Platform-based design 42

43 Transaction-Level Modeling Model the bus system in transaction-level No notion of exact time. But precedence relation of each functional block is properly modeled. Rough estimation on performance is possible. Used as the fastest reference model by each block designer Software design Hardware design Rough Performance Estimation Core model ISS Memory IP IP Transaction-level Bus model Behavior model transaction 43

44 Cycle-Accurate Bus Modeling For more accurate modeling Build a cycle-accurate system model in C or SystemC Replace the transaction-level bus model with a cycle-accurate bus model ARM released a Cycle-Level Interface Specification for this abstraction level. Accurate Performance Estimation Core model ISS Memory RTL model BFM BFM BFM IP Cycle-accurate Bus model IP Behavior model transaction 44

45 AMBA AHB CLI Specification AMBA AHB Cycle Level Interface (CLI) Specification CLI spec defines guidelines for TLM of AHB with SystemC. Interface methods Data structures Header files for SystemC models CLI spec leaves the detailed implementation of the AHB bus model to the reader. master HADDR HWRITE HRDATA HTRANS master Read 10 data from slavex starting Address 0x10 slave slave Cycle-level modeling Transaction-level modeling 45

46 AMBA AHB CLI Specification Example master implementation Transactions are represented as methods in transaction-level modeling. Abstraction levels of each method can be decided as needed such as cycle-count accurate, cycle-accurate, transaction accurate, etc. mastera.h Header mastera.cpp Body SC_MODULE(masterA) { void run(); }; void mastera::run() { bus_request(); has_grant(); init_transaction(); read_from_slave();... } The granularity of transactions are decided according to the verification needs. 46

47 Flexible SoC Verification Environment Algorithm Verification Environment Setup JPEG decoding Functional block model HEAD VLD IDCT DISP Platform-level model HEAD VLD IDCT DISP Build C reference model for the target application. Setup of platform-level verification environment as early as possible SW Model TRS TRS TRS TRS HW Model Memory Timer INTC 47

48 Flexible SoC Verification Environment Algorithm Verification Environment Setup JPEG decoding Functional block model HEAD VLD IDCT DISP Platform-level model HEAD VLD IDCT DISP TRS TRS TRS TRS Transactor connects various types of SW block models with HW bus system. Several types of transactors must be prepared, for example AHB C model AHB HDL model OPB Testbuilder PLB SystemC Memory Timer INTC 48

49 Flexible SoC Verification Environment Socketize IP representation HW: C HDL EDIF SW: native C ISS Processor Core C to HDL Synthesis HW part model C Transactor HDL Transactor EDIF Transactor AHB Transactor AHB Transactor AHB SW part model C ISS Processor Cross-compiler 49

50 Cycle-Level Transactor Generate stimulus at every clock cycle Check the result of DUT at every clock cycle Testbench DUT Cycle-level transactor Testbench Device Driver PCI Channel PCI Controller DUT S/W simulation part FPGA part 50

51 Transaction-Level Transactor Only information to generate transaction is transferred to DUT, i.e., address and data No need to synchronize at every clock cycle Testbench DUT Testbench Device Driver Main Memory DMA Channel PCI Controller Transactor DUT S/W simulation part FPGA part 51

52 Cycle vs. Transaction-level Transactor Cycle-level transactor Synchronized at every clock cycle. Operating speed depends on the number of signals to be transferred. Transaction-level transactor Synchronized at the end of each transaction. Transactor must be designed for each interface standard ex) AHB transactor, SDRAM transactor, IIS transactor 52

53 DFV (Design for verification) : OpenVera (OV) verification IP Reusable verification modules, i.e., 1) bus functional models, 2) traffic generators, 3) protocol monitors, and 4) functional coverage blocks. 53

54 RTL Debugging Feature Gate-level netlist generated from the synthesis tools is difficult to trace manually. Techniques to resolve RTL symbol names from the gatelevel symbol names and to provide debugging environment in RTL name spaces is required. Insert RTL instrumentation IP for debugging Design flow Read RTL design (Verilog, VHDL) Generate instrumented RTL design (spiced with triggering and dump logic) Synthesis Compile (mapping & PAR) DiaLite (Temento), Identify (Synplicity) 54

55 Synthesizable Testbench Prepare a set of programmable test bench module which can be also synthesized into hardware. To verify a DUT, build a test bench using the programmable gmc_cfg_datasize gmc_cfg_msmode test bench. The test bench is applicable to both simulation and emulation in the same fashion. 3 # Set to 32 Bits 0xF # Set to Master TX gmc_cfg_datapath_0x00 # Read/Write to Mem gmc_cmd_send_data 100 # Send 100 Bytes uart_cfg_odd_parity 1 # Set ODD parity Generic Mini-Controller (GMC) 55 from Duolog Technolog

56 Agenda Verify early and in-system Why Verification? Verification Alternatives Verification with Progressive Refinement SoC Verification Co-simulation Co-emulation Concluding Remarks 56

57 SoC Verification Co-simulation Connecting ISS with HDL simulation environment Seamless, N2C Co-emulation Emulation/rapid-prototyping equipments supporting co-emulation ARM Integrator, Aptix System Explorer, AXIS XoC, and Dynalith iprove 57

58 What s the point in SoC Verification? Mixture of SW and HW Let the HW model to cooperate with Processor Model such as ISS or BFM (Bus functional model) Mixture of pre-verified, unverified components Utilize legacy IPs already verified Mixture of different language, different abstraction levels Provide common interface structure between SoC components 58

59 Canonical SoC design flow System Spec. HW-SW Co-Design System Design HW/SW Partitioning HW IP SW IP HW-SW Co- Verification Functional Verification HW Development SW Development Software Verification Gate-Level Verification HW refinement (UT->T->RTL) Gate SW refinement (RTOS mapping) Final code Emulator In-system emulator HW-SW co-debugging 59

60 Tools for HW-SW Co-Verification System Spec. System Design HW/SW Partitioning HW IP SW IP HW-SW Co- Verification Functional Verification HW Development SW Development Software Verification HW refinement (UT->T->RTL) SW refinement (RTOS mapping) High-level synthesis Testbench automation IP accelerator HW-SW co-simulation ISS RTOS simulator 60

61 Tools for System-level Verification System Spec. HW-SW Co-Design System Design HW/SW Partitioning HW IP SW IP System-level design (Performance analysis tools) Hot-spot analyzer High-level cycle count estimation High-level power analysis High-level chip area estimation On-chip-bus traffic estimation 61

62 Co-Simulation Tools Software debugging in ISS and hardware verification in HDL simulator are done in parallel way. Co-simulation stub manages the communication between HDL simulator and ISS. The most accurate solution albeit very slow Debugger Remote Debugging Interface ISS Co-simulation Stub HDL Simulator 62

63 Co-Emulation Tools Link hardware emulators with a processor model running in host machine or an actual processor core module Most emulation and rapid prototyping products support linkage with ISS running in host machine As the emulator runs very fast, speed of ISS including memory access as well as synchronization between emulation and ISS rise as new bottlenecks in verification 63

64 Other components Example) ARM ETM (Embedded Trace Macrocell) Real-time trace module capable of instruction and data tracing dedicated to the ARM core family Triggering enables to focus collection around the region of interest Trace module controls the amount of trace data by filtering instructions or data Only applicable to the ARM core debugging ARM core Memories PC-based debugger Trace port analyzer Trace Trigger ETM Conf. Peripherals JTAG interface 64 Target system with ARM based ASIC

65 Typical Co-Emulation Environment Connect ARM ISS or ARM board to the emulation system. ARM ISS Emulation System ARM ISS can be configured to user s target SoC architecture. SW debugger can be fully utilized. ARM Development Board Emulation System Faster than ISS. Ready-made ARM development boards has fixed architecture which may be different from the user architecture. 65

66 Example 1: ARM Integrator ARM prototyping platform Composed of Platform : AMBA backbone + system infrastructure Core Module : various ARM core modules (up to four) Logic Module : FPGA boards for AMBA IP s Allows fast prototyping of ARM-based SoC Enables co-emulation of both software in ARM processor core and hardware in the FPGA Difficult to debug hardware logic from ARM 66

67 Example 2 : isave/iprove (Dynalith) All-in-one verification : Heterogeneous models including ARM ISS, C hardware model, HDL hardware description SW models run in Linux-based PC HW models run in FPGA s, or as a processor chip HW/SW Co-debugging with Pin Signal Analyzer On-the-fly probing of FPGA internal signals to SRAM Communicate with C model using PCI DMA Design in C C/SystemC/HDL sessions Design in SC I/F protocol I/F protocol FPGA Target board Design in HDL Inter-Lingual Communication Transactor Hardware Processor ISS sessions ISS Transactor Logic Design in EDIF/FPGA Hardware Sessions 67

68 Agenda Verify early and in-system Why Verification? Verification Alternatives Verification with Progressive Refinement SoC Verification Concluding Remarks 68

69 So, in Summary Verification is challenging; It needs strategy! Strategy is to apply each method when appropriate. Verify with Correct Specification In-System Verification Verify as early as possible; Kill the bug when it is small and still isolated in a smaller region. (Kill it before it grows big and kills you(r design and your company).) Accelerate the verification cycle using Efficient debugging tools Hardware Accelerator 69

70 A Tactical Sequence of Applying Various Verification Tools 1 st step: Apply formal methods Static formal verification Assertion-based verification 2 nd step: Simulate IP with transaction level test-bench with cycle-accurate test-bench 3 rd step: Emulate design Emulate IP operation in FPGA In-system IP verification Cycle-level vs. transaction level test-bench 70

71 Concluding Main differences of SoC with ASIC design are Planned IP-reuse Reuse of pre-verified platform Focus on co-verification with software Newly added IP s must be thoroughly verified before its application to SoC. Well-established verification platform allows progressive verification/refinement of each IP, i.e., each SoC component while assuring correct implementation. Powerful HW/SW co-simulation and co-debugging features are required. 71

72 Thank you for your kind attention! 72