Advanced SoC Design Verification: Challenges and Solutions

Design Verification for SoC 晶片系統之設計驗證 熊博安國立中正大學資訊工程學系嵌入式系統實驗室 hpa@computer.orghttp://www.cs.ccu.edu.tw/~pahsiung/http://embedded.cs.ccu.edu.tw/

Contents • SoC Verification Challenges • Verification Methods • Simulation Technologies • Static Technologies • Formal Technologies • Physical Verification and Analysis • SoC Verification Methodologies • Case Studies

What is a System-on-Chip? • An SoC contains: • Portable / reusable IP • Embedded CPU • Embedded Memory • Real World Interfaces (USB, PCI, Ethernet) • Software (both on-chip and off) • Mixed-signal Blocks • Programmable HW (FPGAs) • > 500K gates • Technology: 0.25um and below • Not an ASIC !

Challenges for System-on-Chip Industry “ ... the industry is just beginning to fathom the scope of the challenges confronting those who integrate blocks of reusable IP on large chips.Most of the participants summed up the toughest challenge in one word: verification.” Source: EE Times (Jan. 20, 1997) Report on Design Reuse and IP Core Workshop Organized by DARPA, EDA Industry Council, NIST

System-on-Chip Verification Challenges • Verification goals • functionality, timing, performance, power, physical • Design complexity • MPUs, MCUs, DSPs, AMS IPs, ESW, clock/power distribution, test structures, interface, telecom, multimedia

System-on-Chip Verification Challenges • Diversity of blocks (IPs/Cores) • different vendors • soft, firm, hard • digital, analog, synchronous, asynchronous • different modeling and description languages - C, Verilog, VHDL • software, firmware, hardware • Different phases in system design flow • specification validation, algorithmic, architectural, hw/sw, full timing, prototype

Finding/fixing bugs costs in the verification process System Time to fix a bug Module Block Design integration stage • Increase in chip NREs make respins an unaffordable proposition • Average ASIC NRE ~$122,000 • SoC NREs range from $300,000 to $1,000,000NRE=non-recurring engineering RESPIN

Challenges in DSM technology for SoC • Timing Closure • Sensitive to interconnect delays • Large Capacity • Hierarchical design and design reuse • Physical Properties • Signal integrity (crosstalk, IR drop, power/ground bounce) • Design integrity (electron migration, hot electron, wire self-heating)

Physical issues verification (DSM) • Interconnects • Signal Integrity • P/G integrity • Substrate coupling • Crosstalk • Parasitic Extraction • Reduced Order Modeling • Manufacturability and Reliability • Power Estimation

Physical issues verification (DSM)Interconnects • Scaling technology • They get longer and longer • Increasing complexity • New materials for low resistivity  Inductance and capacitance become more relevant • Larger and larger impact on the design  Need to model them and include them in the design choices (gate-centric to interconnect-centric paradigm)

Physical issues verification (DSM)P/G and Substrate • Analog and Digital blocks may share supply network and substrate • Can I just plug them together on the same chip? Will it work? • The switching activity of digital blocks injects noise current that may “kill” analog sensitive blocks Digital IP Analog

Physical issues verification (DSM)Crosstalk In DSM technologies, coupling capacitance dominates interlayer capacitance  there is a “bridge” between interconnects on the same layer….they interfere with each other!

Physical issues verification (DSM)Parasitic Extraction • Parasitics play a major role in DSM technologies • Need to properly extract their value and model

Physical issues verification (DSM)Reduced Order Modeling • Increasing complexity  bigger and more complex models • E.g. supply grid, parasitics… • Need to find a “reduced” model so that • Still good representation • Manageable size

Physical issues verification (DSM)Manufacturability • Design a chip • Send it to fabrication • ……. • Did I account for the fabrication process variations? • How many of my chips will work? • Just one? All? Most of them? • How good is my chips performance? Design and verification need to account for process variations!

Physical issues verification (DSM)Reliability • Design a chip • Send it to fabrication • ……. • Did I test my design for different kinds of stress? • Is it going to work even in the worst case? • Can I sell it both in Alaska and Louisiana?

Physical issues verification (DSM)Power Estimation • Advent of portable and high-density circuits  power dissipation of VLSI circuits becomes a critical concern Accurate and efficient power estimation techniques are required

Design Productivity Gap Gates / Chip Design Productivity Gap Gates / Hour 1990 1995 2000

SoC Design/Verification Gap System-on-Chip Test Complexity Simulation Performance Simulator Performance Verification Gap Design Complexity (FFs) Source: Cadence

Verification Methods • Simulation Technologies • Static Technologies • Formal Technologies • Physical Verification and Analysis

Simulation Technologies • Event-driven Simulators • Cycle-based Simulators • Rapid Prototyping Systems • Emulation Systems • Speeding up Simulators (C, BFM, ISS,…) • Testing & Coverage-driven Verification • Assertion-based Verification • HW/SW Cosimulation • AMS Modeling and Simulation

S t a t e S t a t e C o m b. L o g i c Hardware Simulation • Event-driven • compiled code • native compiled code (directly producing optimized object code) very slow + asynchronous circuits, timing verification, initialize to known state • Cycle-based + faster (3-10x than NCC) synchronous design, no timing verification, cannot handle x,z states clock

1x .001x 10x Simulation: Perfomance vs Abstraction Cycle-based Simulator Event-driven Simulator Abstraction SPICE Performance and Capacity

Validating System-on-Chip by Simulation • Need for both cycle-based and event-driven • asynchronous interfaces • verification of initialization • verification of buses, timing • Need for mixed VHDL/Verilog simulators • IP from various vendors • models in different languages • SoC verification not possible by current simulation tools • Growing gap between amount of verification desired and amount that can be done • 1 million times more simulation load than chip in 1990 (Synopsys)

Firmware Design Source Code Object Code Algorithm In Circuit Emulator(ICE) Integration Test RTL GATE Behavior Hardware Design Rapid Prototyping Systems

Emulation Systems • Emulation: Imitation of all or parts of the target system by anothersystem, the target system performance achieved primarily byhardwareimplementation • In-Circuit Emulator (ICE): A box of hardware that can emulate theprocessor in the target system. The ICE can execute code in the targetsystem’s memory or a code that is downloaded to emulator. • ICE also can be fabricated as silicon within the processor-core:provides interface between a source level debugger and aprocessorembedded within an ASIC • Provides real-time emulation • Supports functions such as breakpoint setting, single step execution, trace display and performance analysis • Provide C-source debugger • Examples: EmbeddedICE macrocell in ARM SY7TDM1, NEC 850 family of processors, LSI Logic

Embedded ICE Macrocell 2 EmbeddedICE Macrocell EmbeddedICE Macrocell ARM Core 0 ARM7TDMI Control 1 Data Addr Traditional boundary scan Data bus scan chain TAP 5 pin JTAG Interface Source: ARM

Embedded ICE in ARM7TDMI Core EmbeddedICE Interface ASIC EmbeddedICE macrocell Debug Host ARM Source: ARM

Target system Bread board for emulator In-Circuit Emulator Create by using standard LSI , FPGA & G/A Debugging environment for CPU core Source: NECEL

Enhancing Simulation Speed Using Simulation Models • Hardware model • Behavioral model in C • Bus-functional model (BFM) • Instruction-Set simulation (ISS) model • instruction accurate • cycle accurate • Full-timing gate-level model • encrypted to protect IP

Hardware Model • Use the actual physical device to model its own behavior during simulation • Advantages: accuracy, full device functionality, including any undocumented behavior • Disadvantages: delivers 1 to 10 instructions/sec, cost • Example • Logic Modeling (Synopsys) Hardware Models

Behavioral Model • Behavior of the core modeled in C • Example: Memory models from Denali • 30-70% of system chip area is memory => power, latency, area of chip • In typical simulation, conventional models consume as much as 90% of workstation memory • C models of DRAM, SRAM, Flash, PROM, SDRAM, EEPROM, FIFO • RAMBUS, Configurable Cache • parameterizable models, common interface to all simulators • allows adaptive dynamic allocation, memory specific debugging

Bus Functional Model (BFM) • Idea is to remove the application code and the target processor from the hardware simulation environment • Performance gains by using host processor’scapabilitiesinstead of simulating same operation happening on target processor • Varying degrees of use of host processor leads to different models • Bus functional model • only models the interface circuitry (bus), no internal functionality • usually driven by commands: read, write, interrupt, … • bus-transaction commands converted into a timed sequence of signal transitions: fed as events to traditional hardware simulator • Bus functional model emulates“transactions”: • Read/Write Cycles (single/burst transfers) • Interrupts

Bus Events I/O transactions Compile to host processor Bus functional model Hardware Simulator App code Compiled Code Simulation • Host code not equal to Target code • Low-level debugging not possible • E.g. observing processor internal registers • Measurements may be inaccurate • E.g. cycle counts

Instruction Set Simulation (ISS) • Full functional accuracy of the processor as viewed from pins • Operations of CPU modeled at the register/instruction level • registers as program variables • instructionsasprogramfunctions which operate on register values • Data path that connects the registers are abstracted out • Allows both high-level and assembly code to be debugged • Instruction Accurate • accurate at instruction boundaries only • correct bus operations, and total number of cycles, but no guarantee of state of CPU at each clock cycle; inaccuracy due to bus contention • Cycle Accurate • guarantees the state of the CPU at every clock cycle • guarantees exact bus behavior • slower than instruction-accurate, but faster than full behavioral model Source: LSI Logic, Mentor Graphics

Register view Memory view Source-level debug ISS Example • Example Simulator: Microtec XRAY Sim™ • Fast: 100,000 instructions/sec • Software debug: source code debugging, register and memory views

RAM Timing Wrapper V851 in C - Model Soft ICE (for emulation & debugging) User Logic Verilog Interface ROM Verilog Example of Simulation Models • NEC provides the following simulation models: • Behavioral C model: used in early design stage, for functional verification, fastest execution • RTL model with timing wrapper: for accuratetiming and function verification • Verilog gate-level model: for final design verification, very slow

Testing • Verification environment • Commonly referred as testbench • Definition of a testbench • A verification environment containing a set of components [such as bus functional models (BFMs), bus monitors, memory modules] and the interconnect of such components with the design under-verification (DUV) • Verification (test) suites (stimuli, patterns, vectors) • Test signals and the expected response under given testbenches

Testbench Design • Auto or semi-auto stimulus generator is preferred • Automatic response checking is highly recommended • May be designed with the following techniques • Testbench in HDL • Testbench in programming language interface (PLI) • Waveform-based • Transaction-based • Specification-based

Types of Verification Tests • Random testing • Try to create scenarios that engineers do not anticipate • Functional testing • User-provided functional patterns • Compliances testing • Corner case testing • Real code testing (application SW) • Avoid misunderstanding the specification

Types of Verification Tests • Regression testing • Ensure that fixing a bug will not introduce other bugs • Regression test system should be automated • Add new tests • Check results and generate report • Distribute simulation over multiple computer • Time-consuming process when verification suites become large

Coverage-driven Verification • Coverage reports can indicate how much of the design has been exercised • Point out what areas need additional verification • Optimize regression suite runs • Redundancy removal (to minimize the test suites) • Minimizes the use of simulation resources • Quantitative sign-off (the end of verification process) criterion • Verify more but simulate less

The rate of bug detection source : “Verification Methodology Manual For Code Coverage In HDL Designs” by Dempster and Stuart bugs

Coverage Analysis • Dedicated tools are required besides the simulator • Several commercial tools for measuring Verilog and VHDL code coverage are available • VCS (Synopsys) • NC-Sim (Cadence) • Verification navigator (TransEDA) • Basic idea is to monitor the actions during simulation • Require supports from the simulator • PLI (programming language interface) • VCD (value change dump) files

Analysis Results • Verification Navigator (TransEDA) Untested code line will be highlighted

Assertion-Based Verification • Assertion-based verification (ABV) solutions are gaining in popularity • Assertions are statements of designer assumptions or design intent • Assertions should be inherently reusable • These supplement, not replace, traditional simulation tests • Design and verification engineer knowledge is leveraged • Both design observability and design controllability can be improved • Assertions enable formal verification

Assertions • Assertions can capture interface and bus rules • In ABV, protocol monitors are written using assertions • Each individual protocol rule is captured by an assertion, usually temporal (multi-cycle) in nature • Example: Signal A should assert between 3 and 5 cycles after signal B, but only if signal C is deasserted • Internal assertions capture design intent • Example: this FIFO should never receive a write when it is already full • Example: this state machine variable should always be encoded as one-hot • These improve observability in simulation but still rely on tests for stimulus

Assertion Checkers • Checkers check the assertion conditions • Checker “fire” on indications of bugs (e.g., FIFO write when full) • Improve observability but still rely on tests for stimulus • Certain types of checkers can be inferred directly from the RTL code • Example: Arithmetic overflow on a computation • Example: Proper synchronization across an asynchronous clock domain boundary • The most valuable assertion checkers come from information in the designer’s head • It must be easy to capture assertions

Assertion Capture Checkers can be written in many ways • In a testbench language (C, C++, e, Vera, etc.) • Directly in RTL (Verilog or VHDL) • With RTL assertion constructs (VHDL, SystemVerilog) • Using assertion libraries (OVL) • In a formal property language (PSL, Sugar, ForSpec, etc.) • Embedded in RTL with pseudo-comments (used by 0-In and several other EDA vendors) • Assertion capture should be as easy as possible • Designers don’t want to learn a new language • Assertion checker libraries provide a lot of leverage

Complete ABV Flow RTL Design Automatic RTL Checks Assertions Assertion Library Assertion Compiler Testbench Standard Verilog Simulator Coverage Reports Simulation Formal Model Compiler Formal Verification Formal Metrics Static Formal Verification Dynamic Formal Verification

Advanced SoC Design Verification: Challenges and Solutions