Sep. 18, 2003/ Portland Hilton Chong-Min Kyung, KAIST

Sep. 18, 2003/ Portland Hilton Chong-Min Kyung, KAIST
IEEE International SOC Conference Current Status and Challenges of SoC Verification for Embedded Systems Market Sep. 18, 2003/ Portland Hilton Chong-Min Kyung, KAIST

Agenda Why Verification ? Verification Alternatives
Languages for System Modeling and Verification Verification with Progressive Refinement SoC Verification Concluding Remarks

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. 1996 300K gates Code Verify (30 ~ 40%) Synthesis P&R 2000 1M SoC Code Verify (50 ~ 80%) Synthesis P&R Verification methodology manual, 2000- TransEDA

Percentage of Total Flaws
About 50% of flaws are functional flaws. Need verification method to fix logical & functional flaws From Mentor presentation material, 2003

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?

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 Design Device Production Verification methodology manual, 2000 – TransEDA

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 HW simulation acceleration (<10KCPS) Cycle-base simulation (<1KCPS) Simulation performance Verification complexity Event-base simulation (<10CPS) Complex ASIC Medium ASIC Small ASIC Design complexity System-on-a-chip verification, 2001 – P.Rashinkar

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.

Verification Challenges
Specification or Operating Environment is Incomplete/Open-Ended. (Verification metric is never complete like last-minute ECO.) The Day before Yesterday’s tool for Today’s Design. Design productivity grows faster than Verification productivity.

Simulation Hardware-accelerated simulation Emulation Prototyping Formal verification Semi-Formal (Dynamic Formal) verification Languages for System Modeling and Verification Verification with Progressive Refinement SoC Verification Concluding Remarks

Overview of Verification Methodologies
Prototyping Faster speed, closer to final product Emulation Hardware Accelerated Simulation Simulation Basic verification tool Semi-formal Verification Formal Verification Bigger coverage

Software Simulation Dynamic verification method
Bugs are found by running the design implementation. Thoroughness depends on the test vector used. Some parts are tested repeatedly while other parts are not even tested. Other parts are not even tested. Testbench DUV a = 1; #20 b = 1; $display (“status is = %d”,c); ... Some part of the design is tested repeatedly.

Cycle-Based Simulation
Simulate the behavior of the design cycle-by-cycle. Cycle-accurate information is provided as a result of simulation. Only signals at the flip-flop input are evaluated to be stored, not internal signals of combinational logic. Combinational logic Combinational logic Combinational logic Combinational logic Combinational logic

Cycle-based vs. Event-driven
Timing resolution Clock cycle User-defined minimum delay Evaluation time point Rising/falling/both clock edges At the occurrence of events Evaluation node Every flip-flop boundary At the output of every logic gate on the event propagation path Simulation time Proportional to the (number of cycles) times (C/L size * number of F/F’s) Proportional to the number of events (circuit size* no. of cycles*event density)

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.

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. Hardware Accelerator Simulation environment Testbench Module 2 is synthesized & compiled into FPGAs Module 0 Module 1 Module 2

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.

Challenges Overall speed depends on the communication between simulator and hardware. Execution time decomposition in a typical case of a PCI-based hardware accelerator ; SW simulator + PLI/FLI + Driver overhead : 38%  It is desirable to reduce the driver call overhead. PCI overhead : 44%  Can be reduced by using DMA data transfer. Hardware Accelerator 18% SW Simulator + PLI/FLI + Device Driver 38% PCI overhead 44%

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 Emulation Hardware Accelerated Simulation Simulation

Emulation User logic design is mapped to emulation board with multiple FPGA’s or special processors. The emulation board has external interconnection hardware that emulates the pins of final chip. Emulation hardware with multiple FPGAs Logic design & Design mapping > & + External pins

Emulation Pros Fast (500K cycles/sec)
Verification on real target system. Cons 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.

General Architecture of Emulation Systems
Many FPGA’s are interconnected together for large gate capacity. Emulation systems on the market have differences in their interconnection architectures. FPGA 0 FPGA 1 Crossbar (Switch) FPGA 2 FPGA 3

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)

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

Prototyping Pros Higher (than emulation) clock rate (over 1M cycles/sec) due to specific design of prototyping board. Components as well as the wiring can be customized for the corresponding application. Can be carried along. (Hardware Emulation? Forget it!) Cons Not flexible for design change (Every new prototype requires a new board architecture. / Even a small change requires a new PCB.)

A Prototyping Example Prototype of 4-Port Gigabit Ethernet Switch
Switch board Prototype of 4-Port Gigabit Ethernet Switch Two Xilinx Virtex-E 2000 FPGAs are on FPGA board. Four FPGA boards are used. Processor board contains PCI bridge and MPC860 microprocessor. Xilinx FPGA Processor board PCI bridge MPC860 microprocessor Courtesy of Paion, Inc.

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

Formal Verification Objective Pros Cons
Check properties of model with all possible conditions Pros Assures 100% coverage. Fast. Cons Works only for small-size finite state systems. Uncomfortable due to culture difference (E.g., engineers are not familiar with the use of temporal logic used for “property” description in Model Checking)

Formal Verification : Equivalence Checker
Equivalence checker compares the golden model with the refined model. Functional representations are extracted from the designs and compared mathematically. Pros Exhaustive design coverage Very fast Cons Memory explosion Tools such as LEC (Verplex), Formality (Synopsys), FormalPro (Mentor) supports Equivalence checking. Golden Model ? Refined Model =

Formal Verification : Model Checking
Model checking verifies that the design satisfies a property specified using temporal logic. Computational Tree Logic Specify the temporal relationship among states in FSM with temporal operators; A (always), E (exists) – path quantifier G (global), F (future), X (next), U (until) – temporal modality ? Computational Tree Logic Design 

Formal Verification Challenges
The most critical issue of formal verification is the “state explosion” problem. The application of current formal methods are limited to the design of up to 500 flip-flops. Researches about complexity reductions are : Reachability analysis Design state abstraction Design decomposition State projection

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. Key features of assertions 1. Error detection : If the assertion is violated, it is detected by the simulator. 2. Error isolation : The signals related to the violated assertion are identified. 3. Error notification : The source of error is reported to the user.

Example of assertion-based bug detection Identify signals related to the violated assertion PCI DMA Controller event devsel : if (FRAME=0) [1..4] (DEVSEL=0) assert(devsel); PCI “devsel” assertion is violated! Report to the user!!

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

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

Coverage metrics for coverage-directed verification Code-based metrics Line/code block coverage Branch/conditional coverage Path coverage Circuit structure based metrics Toggle coverage Register activity State-space based metrics Pair-arcs : usually covered by Line + condition coverage Spec.-based metrics % of specification items satisfied

Coverage Checking tools VeriCover (Veritools) SureCov (Verisity) Coverscan (Cadence) HDLScore, VeriCov (Summit Design) HDLCover, VeriSure (TransEDA) Polaris (Synopsys) Covermeter (Synopsys)

Semi-Formal Verification
Pros Designer can measure the coverage of the test environment as the formal properties are checked during simulation. Cons The simulation speed is degraded as the properties are checked during simulation. Challenges There is no unified testbench description method. It is difficult to guide 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.

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

Design Complexity Gate counts Comments
Simulation/Semi-formal verification Unlimited Emulation/Hardware-accelerated simulation 1M~16M gates Depends on the number of FPGA’s in the architecture Prototyping 1M~5M gates Depends on the components on the board Formal verification < 10K gates Limited to about 500 flip-flops due to state explosion

Verification Time vs. Coverage
Semi-formal Emulation /Accelerated simulation Prototyping Simulation Redirection of testbench constraints Verification Time Simulation setup Semi-formal setup Emulation setup Prototyping setup

Languages for System Modeling and Verification System modeling languages Testbench automation & Assertion languages Verification with Progressive Refinement SoC Verification Concluding Remarks

Accellera Formed in 2000 through the unification of Open Verilog International and VHDL International to focus on identifying new standards, development of standards and formats, and to foster the adoption of new methodologies.

Accellera Three different ways of specifying Assertions in Verilog designs; OVL (Open Verification Library) PSL (Property Specification Language) Native assertion construct in System Verilog

ACCELLERA APPROVES FOUR NEW DESIGN VERIFICATION STANDARDS
June 2, Accellera, the electronics industry organization focused on language-based electronic design standards approved four new standards for language-based design verification; Property Specification Language (PSL) 1.01, Standard Co-Emulation Application Programming Interface (SCE-API) 1.0, SystemVerilog 3.1 and Verilog-AMS 2.1.

Accellera's PSL (Property Specification Language)
Gives the design architect a standard means of specifying design properties using a concise syntax with clearly defined formal semantics. Enables RTL implementer to capture design intent in a verifiable form, while enabling verification engineer to validate that the implementation satisfies its specification with dynamic (that is, simulation) and static (that is, formal) verification.

SCE(Standard Co-Emulation Interface)-API
SCE-API standard defines a high-speed, asynchronous, transaction-level interface between simulators or testbenches and hardware-assisted solutions such as emulation or rapid prototypes.

Language Heritage for SoC Design
New languages are developed to fill the productivity gap. JAVA Language for Software development C++ Assembly C SystemC Language for Hardware test TestBuilder Vera SystemVerilog Language for Hardware description Verilog Schematic VHDL Past Present Future

SystemC SystemC is a modeling platform consisting of
A set of C++ class library, Including a simulation kernel that supports hardware modeling concepts at the system level, behavioral level and register transfer level. SystemC enables us to effectively create A cycle-accurate model of Software algorithm, Hardware architecture, and Interfaces of System-on-a-Chip. Program in SystemC can be An executable specification of the system.

SystemC Modules, ports, and signals  for hierarchy
Processes  for concurrency Clocks  for time Hardware data types  for bit vectors, 4-valued logic, fixed-point types, arbitrary precision integers Waiting and watching  for reactivity Channel, interface, and event  for abstract communications sc_main Process Process Module Module Module Process Process Process Process Process Process Process

Abstraction Levels of SystemC
Algorithm level Function hierarchy C/C++ Untimed functional level Modular structure Timed functional level Timing information Bus-cycle accurate level Intra module: un-timed Inter module: cycle accurate Cycle accurate level Cycle accurate SystemC Behavioral level Synthesizable RT level Verilog/VHDL Gate level

Test-bench automation
Why is test-bench automation required? Test-bench for IP can be more complex than the IP itself. Manual description of the test-bench is a time-consuming job. Simulating the whole test-bench in HDL yields excessive verification time. Players TestBuilder (Cadence) Closer to C, integrated to SystemC VERA (Synopsys) Closer to Verilog, integrated to SystemVerilog

(Design Under Verification)
TestBuilder Transaction-Based Verification Functional verification in higher-level abstraction Engineer develops tests from a system-level perspective Advantages Enhance reusability of each component in the test-benches Improve debugging and coverage analysis Transaction Level Signal Level TVM DUV (Design Under Verification) Tests TVM: Transaction Verification Model

TestBuilder TVM (Transaction Verification Model) Testbuilder/C/C++ HDL
Transaction Level Signal Level Tests TVM DUV tx.send_packet(..){ header = “hd”; address=0xff0011; data = 0xff0011; } while(){ tx.send_packet(); mem.expect_write(); .. } TVM (Transaction Verification Model) Translates a bus cycle command to a signal waveform May be described in C API or Verilog PLI

Constraints written in
VERA (Synopsys) Inputs to VERA DUT dut.v vera.vr Constraints written in OpenVera syntax VERA Functional verification language for testbench description OpenVera is a language specification. VERA (Synopsys) is a testbench generation tool.

Generated files from VERA
Inputs to VERA OpenVera source codes are compiled and runs with HDL simulator in which DUT is simulated. DUT Vera constraints dut.v vera.vr VCS (simulator) top.v dut.shell.v dut.vro dut.v VERA Generated files from VERA top.v dut.shell.v dut.vro Simulator simulates and report file is generated. Template top module PLI function wrapper Vera object file. (binary PLI functions or DirectC objects)

Generated files from VERA
OpenVera Assertions Inputs to VERA DUT Vera constraints dut.ova dut.v vera.vr Simulator simulates and report file is generated. VCS (simulator) top.v dut.shell.v dut.vro dut.v dut.ova VERA Generated files from VERA top.v dut.shell.v dut.vro Assertion is also supported in OpenVera. Template top module PLI function wrapper Vera object file. (binary PLI functions or DirectC objects)

SystemVerilog SystemVerilog 3.1 provides design constructs for architectural, algorithmic and transaction-based modeling. Adds an environment for automated testbench generation, while providing assertions to describe design functionality, including complex protocols, to drive verification using simulation or formal verification techniques. Its C-API provides the ability to mix Verilog and C/C++ constructs without the need for PLI for direct data exchange.

SystemVerilog New data types for higher data abstraction level than Verilog Structures, classes, lists, etc. are supported. Assertion Assertions can be embedded directly in Verilog RTL. Sequential assertion is also supported. Encapsulated interfaces Most system bugs occur in interfaces between blocks. With encapsulated interfaces, the designer can concentrate on the communications rather than on the signals and wires. DirectC as a fast C-API C codes can be called directly from the SystemVerilog codes.

Key Components of SystemVerilog
Verification Testbench Assertions DirectC Design Enhanced Concise design New Data types Interface Verilog features Entity Verilog Verilog

System Description Languages Summary
Languge Pros Cons C/C++ Easy to write test vectors/environment Unable to handle some hardware environments. HDL (Verilog, VHDL) Familiarity Easy to describe H/W designs Focuses on the lower-level designs. Improper for system modeling. SystemC Easily connected to C/C++ codes. Easy to model system behaviors. Limited tools (simulation, synthesis, etc.) SystemVerilog Easy to learn for the HDL designers. Few tools (simulation, synthesis, etc.)

Languages for System Modeling and Verification Verification with Progressive Refinement Flexible SoC verification environment Debugging features Cycle vs. transaction mode verification Emulation products SoC Verification Concluding Remarks

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

Conventional SoC Design Flow
Reference C Model Design Exploration Simulation speed is too low Applicable too late Use more abstract simulation model Build SoC emulation platform ASAP C code RTL HDL Model Co-Simulation C code Gate-level Model Co-Emulation

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 Core model Behavior model --- Memory IP IP ISS Rough Performance Estimation ... transaction Transaction-level Bus model

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. Core model Behavior model Memory RTL model IP ISS --- --- IP Accurate Performance Estimation ... transaction --- BFM BFM BFM Cycle-accurate Bus model

AMBA AHB CLI Specification
AMBA AHB Cycle Level Interface (CLI) Specification Released on July 23, 2003 by ARM. 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. Read 10 data from slaveX starting Address 0x10 master HADDR master HWRITE HRDATA HTRANS slave slave Cycle-level modeling Transaction-level modeling

AMBA AHB CLI Specification
Example master implementation Transactions are represented as methods in transaction-level modeling. The abstraction levels of each method can be decided as needed such as cycle-count accurate, cycle-accurate, transaction accurate, etc. Header Body masterA.h masterA.cpp 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.

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

Algorithm 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 JPEG decoding Functional block model HEAD VLD IDCT DISP Verification Environment Setup Platform-level model HEAD VLD IDCT DISP TRS TRS TRS TRS Memory Timer INTC

Socketize IP representation HW: C  HDL  EDIF SW: native C  ISS  Processor Core C to HDL Synthesis C HDL EDIF HW part model Transactor Transactor Transactor AHB AHB AHB Transactor Transactor Processor SW part model C ISS Cross-compiler

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

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 DUT Testbench Device Driver Main Memory PCI Controller Transactor DUT Testbench DMA Channel S/W simulation part FPGA part

Cycle vs. Transaction-level Transactor
Cycle-level transactor Synchronized at every clock cycle. Transactor can be automatically generated according to the pin count. Operating speed depends on the number of signals to be transferred. Transaction-level transactor Synchronized at the end of each transaction. Transactor generates all necessary signals for DUT to properly transfer the data. Transactor must be designed for each interface standard ex) AHB transactor, SDRAM transactor, IIS transactor

Example) iPROVE Technology
PCI-based Simulation Accelerator Cycle-level verification Seamless integration with the HDL testbench. Up to 100K cycles/sec speed. (1000 times faster than SW simulation) Transaction-level verification Up to 33M cycles/sec speed. (330K times faster than SW simulation) Automatically generated module DUT Test Signal information Signals Test Transactor DUT Transactions Signals

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

Companies providing OpenVera Verification IP
ControlNet IndiaIEEE 1394, TCP/IP Stack GDA TechnologyHyperTransport HCL TechnologiesI2C IntegnologySmart Card Interface nSysSIEEE 1284, UART Qualis DesignEthernet 10/100, Ethernet 10/100/1G, Ethernet 10G, PCI-X, PCI, PCI Express Base, PCI Express AS, b, ARM AMBA AHB, USB 1.1, USB 2.0 Synopsys, Inc.AMBA AHB, AMBA APB, USB, Ethernet 10/100/1000, IEEE 1394, PCI/PCIx, SONET, SDH, ATM, IP, PDH

Debugging Design in the FPGA
Embed logic analyzer with user design in EDIF format Logic to store pre-registered signals into the probing memory. Logic for trigger condition generation. Triggering condition is dynamically configured. Internal node extraction Sometimes the designer wants to watch internal nodes in the design. Internal node probing enables this by wiring-out the internal nodes to the boundary of the DUT top block. Top block DUT Built-In Logic Analyzer Sub-block External Dump Memory Internal node BILA, Dynalith Systems

RTL Debugging Feature Emulation is based on gate-level netlist.
Gate-level netlist generated from the synthesis tools has too complex name styles difficult to trace manually. Techniques to resolve RTL symbol names from the gate-level 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)

RTL Debugging Feature Instrumentation IPs for debugging logic blocks mapped into FPGAs. Trigger Logic Equation Module History Register Transaction Register Random Generator Traffic Analyzer Instrumentation IPs are interconnected to support various configurations. Structures of the RTL design Interconnection of instrumentation IPs DiaLite from Temento

FPGA-based Debuggers Debugger Level Memory Control ports
Triggering conditions Dynalith Systems BILA Netlist level External memory PCI Dynamically configurable without recompiling FPGA Temento DiaLite RTL Block memory of FPGA JTAG signals mapped to user I/O ports Synplicity Identify RTL Block memory of FPGA Dedicated JTAG Ports of FPGA

Connecting Actual Chip to the Simulator
Building a correct and fast reference model for the hardware is very difficult.  Use the actual discrete chip for the IP (or FPGA). Control the clock signal to the actual chip (or FPGA), i.e, slow down and synchronize with the HW simulator and SW debugger in the host machine. Application FPGA prototyping HW/SW co-verification Silicon validation from SimPOD

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 test bench. The test bench is applicable to both simulation and emulation in the same fashion. gmc_cfg_datasize 3 # Set to 32 Bits gmc_cfg_msmode 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) from Duolog Technolog

Large-Scale Emulators
Celaro, Mentor Massive array of FPGA’s Distributed compilation RTL debuggability Full visibility without re-compilation VStation, Mentor (IKOS) Reduced routing problem by multiplexing multiple physical signal lines to a virtual wire. Palladium, Quickturn (Cadence) Use custom processor-array instead of FPGA Support synthesizable testbench Support multi-user operation

Simulation Acceleration
Use one or several large-scale FPGA’s instead of array of small FPGA’s Reduce pin limitation overhead between FPGA’s Utilize advanced features of state-of-the-art FPGA’s Commercial products Eve – ZeBu ALATEK – HES Dynalith – iPROVE Test-bench running in host machine IP under verification PCI Bus

Mapping by running testbench
iPROVE Technology Design flow synthesis P&R Mapping by running testbench compilation Debugging with BILA execution

Languages for System Modeling and Verification Verification with Progressive Refinement SoC Verification Co-simulation Co-emulation Concluding Remarks

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, Dynalith iPROVE

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

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

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

Tools for System-level Verification
Spec. HW-SW HW IP System Co-Design Design SW IP HW/SW Partitioning 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

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 Commercial Products Eaglei (Synopsys), Seamless (Mentor) Debugger ISS HDL Simulator Co-simulation Stub Remote Debugging Interface

Instruction Set Simulator
Interpretive ISS Slow but flexible and accurate Compiled ISS Fast and accurate but applicable only for static programs Static vs. dynamic Depending on the code generation is done in static or dynamic due to cache miss, branch prediction and self-modifying code, etc. Native Code ( not an ISS ) Fast but not accurate I/O handling problem while(true) { inst = fetch( pc ); opcode=decode(inst); switch( opcode ){ … case ADD: … break; } } Main loop of interpretive ISS

Instruction Set Simulator
Execution speed Native code > Static compiled ISS > Dynamic compiled ISS > Interpreted ISS Accuracy Native code < Static compiled ISS = Dynamic compiled ISS <= Interpreted ISS

Seamless (Mentor) Seamless and C-Bridge enables co-verification of ISS(Processor) + HDL + C Hardware model Full visibility and dynamic performance estimation. Supports various CPU’s (over 100 models) The communication between the S/W and the H/W is optimized to maximize the verification performance. from Mentor

N2C A set of tools allowing co-simulation of the system described in various abstraction levels Un-timed C Timed functional description Behavioral bus cycle accurate description RTC (Register Transfer C) HDL with C Interface synthesis to enable platform exploration Interface synthesis make it possible to verify the performance of each platform efficiently in the early design stage. Solving Hardware/software partitioning problems. Deciding bus architecture of the SoC.

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

Example) ARM ETM (Embedded Trace Macrocell)
PC-based debugger 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 Trace port analyzer JTAG interface ETM ARM core Trace Conf. Trigger Other components Memories Peripherals Target system with ARM based ASIC

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

ARM Integrator ARM prototyping platform Composed of the followings
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 logics from ARM

XoC (Axis) ARM core module is connected to Axis’s FPGA arrays.
Source level debugging for both hardware and software HW/SW logic simulation hot swapping  VCD on demand Software instant replay  Correlate bus transaction with software instruction ARM Development board from Axis

System Explorer (Aptix)
Backplane with FPID’s (Field-Programmable Interconnect Device) and connector array. ARM plug-in module is inserted to one portion of connector array. System Explorer ARM7TDMI Plug-in Module from Aptix

ASIC Verification Methods
Running Speed Ideal Verification Solution Make it faster Make it cheaper 100MHz Real Silicon 10MHz Rapid Prototype 1MHz HW Emulator 100KHz 10KHz There are many verification solutions to get working silicon. S/W simulation is most popular and basic one. Although it is cheap solution, it can only run around 10 to 100 Hz speed. To overcome this speed problem, hardware accelerator can be a next solution, But it still provide only around 1 KHz speed. H/W emulation usually utilizes a bunch of FPGA and emulates logics up to 1 MHz. Rapid prototyping system utilizes pre-verified IP-blocks instead of FPGA. It seems to be suitable for IP-based ASIC design, but cost high And 10 MHz speed is not sufficient. Considering that most logic today runs over 30 or 60 MHz even over 100 MHz. Here we are longing to have an ideal verification solution that costs low, but runs fast. That’s it. iSAVE costs one-tenth of other H/W emulator. iSAVE runs around 50 to 60 MHz which means that runs ten times faster than others. 1KHz HW Accelerator 100Hz SW Simulator 10Hz Investment

iSAVE-MP (Dynalith) iSAVE-MP main iSAVE-MP Target Interface
GUI windows Decoded image MPEG Board

Inter-Lingual Communication
iSAVE-MP (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 Debugging with PSA Probe FPGA internal signals values to SRAM memory on the fly.  fastest operating speed, wide and deep sampling window Communicate with C model using PCI DMA C sessions ARM sessions Design in C Design in C Design in C Design in C FPGA FPGA Inter-Lingual Communication I/F protocol I/F protocol Transactor Transactor Design in EDIF Design in EDIF Target board

Tools for SoC Design Tools Pros Cons ADS
Required tool for ARM SW development No consideration about HW IP’s. ARM Real-Time Debuggers SW programming is easy on ARM-based prototyping hardware or SoC. No consideration about debugging of HW IP’s. Seamless Cosimulation environment is supported. Many CPU types Low speed N2C C and SystemC languages supported. ARM Integrator Semi-customization using modules is possible. HW prototyping with ARM ARM SW debugging through ETM & ETB. Complete customization is not possible. Debugging of IP embedded in FPGA is not easy.

Tools for SoC Design Tools Pros Cons XoC System Explorer iPROVE/iSAVE
Cosimulation with ARM ARM SW debugging though ETM & ETB HW IP debugging Long compilation time System Explorer Module-based customization Cosimulation environment Manual setup required iPROVE/iSAVE Cosimulation with ARM ISS SW debugging through ISS HW debugging is supported. Low cost

Languages for System Modeling and Verification Verification with Progressive Refinement SoC Verification Concluding Remarks

Concluding Remarks Verification is challenging; It needs strategy!
Starategy is to apply each method when appropriate. Verify as early as possible; Catch the bug when it is small and still isolated in a smaller region. (Don’t wait until it grows and kills you.) 1st step: Apply formal methods Static formal verification Assertion-based verification 2nd step: Simulate IP with transaction level test-bench Test-bench automation tools 3rd step: Emulate design Emulate IP operation in FPGA In-system IP verification Cycle-level vs. transaction level test-bench

Concluding Remarks 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 utilizing automated testbench and formal methods, if possible. Well-established emulation platform helps, Progressive refinement of newly added SoC components Early development and verification of software Powerful debugging features handling both hardware part and software part are required. Language, Tool/Data Interfaces need standardization. DFV (Design for Verification) ; You lose in the beginning, but will win later, like Design for Reuse.

Thank You!!

In-System Verification (CoolChips)

Languages for System Modeling and Verification In-system Verification of Processor Cores and Software Verification with Progressive Refinement SoC Verification

What is ISV? ISV = In-System Verification When is ISV required? vs.
Design refinement is done down along the design hierarchy by comparison between design levels. When test vector is difficult to generate C1: ISS (Instruction Set Simulator) C2: Cycle-based Model C3: RTL Model specification specification C1 C2 vs. C3 Cn Cn

ISV for Micro-processor
In-system verification of a micro-processor confirms its correct behavior in its real operating environment. Co-verification of processor cores (as well as software) and hardware logic, which is necessary in SoC development, can be performed similarly. Micro- processor chip Processor core system Hardware logic

What is ISV? (cont’d) system chip HW chip I/F HW (slowed)
2) In-system operation : confirm correct behavior in system environment system chip HW (FPGA) chip I/F HW (slowed) (a) simulation (c) emulation SW SW SW HW (b) all-software (d) Virtual Chip

Simulation Consistency check between models of different abstraction levels Instruction Set Simulator (behavioral) RTL model (structural) Test Vector Test Pattern Random Pattern Test Program Application Program SW Stimulus at the I/F

Various Levels of Design Verification (Test Vectors in Simulation)
High efficiency = # of bugs detected size of test vector -Confined to the designer’s understanding -Covers rare cases, -Automatic generation -Coverage not reliable -Good compromise between coverage & efficiency as benchmark -Requires many programs to obtain sufficient coverage -Simulates real situations, -High coverage -Excessive verification -Low efficiency Advantage Disadvantage Test pattern Random program Application

All-Software Approach
All System Parts are modeled in Software. Test Vector System Software (BIOS, OS) Application Programs Helps detect bugs When the situation is difficult to reproduce with random patterns (i.e., Instruction’s sensible behavior requires some pre-setting) When instruction behavior is complex, i.e., protected-mode CISC instructions Modeling system parts is difficult when no source code for the application programs is available SW (chip) SW (system)

Emulation Mapping Gate-level Model in FPGA-based System Fast ISV HW
in simulation speed in design stage Slowed-down System HW in FPGA Time second seconds minutes hours day days months 1 10 2 16 3 12 Speed up factor 107 106 105 104 103 102 101 Actual Hardware Logic Emulation Software Simulation Verification Gap

Concurrent Verification
Without Emulation Sequential Verification System SW Design Code Debug Integration Hardware HW Design Build Debug Integration CHIP Design Fab Debug Back annotation Time With Emulation Concurrent Verification SW Design Code HW Design Build CHIP Design Fab Early to HW integration Final Integration Market!! HW emulation Chip & HW Debug Debug Debug Sys integration & SW Debug Back annotation

Bridge between SW and HW
Virtual Chip Validate the functionality of a micro-processor in real situations, i.e., with real-world vectors and real hardware environment. verify the algorithm in the early design stage SW HW Functional model Bus System Description In PL (C, C++…) Processor Bridge between SW and HW In HDL (Verilog...) FPGA

(pin signal generator)
Virtual Chip [DAC98] [DAC98] Virtual Chip: Making Functional Models Work on Real Target System Example: Simulating ISS with real target system ISV with application program in early design stage Target board Host computer cable PSG (pin signal generator) daughter board Chip Model;ISS

Why Virtual Chip ? No need to model external system in software as in
all-software approach Inexpensive solution compared to emulator small number of FPGA’s HW slow-down is not necessary, i.e., no need to modify the target system for emulation Hardware Emulation slowed Bus Model Target Board Virtual Chip normal Bus Model Target Board Buffer

Without CPU PC running ISS

Benefit of Virtual Chip in Design Time
idle Conventional design flow Architectural model RTL Gate-level H/W Emulation Verification w/ H/W H/W prototype (H/W emulation) Board design Application S/W Virtual-Chip-based design flow (Virtual Chip) Design time is drastically reduced

Overall Functional Verification Flow
Architecture Define Microcode Description RTL Description (Verilog HDL) Synthesis RTL Simulation Microcode Verifier Gate Level Simulation For version control Hardware Emulation Verification Completed

Microprocessor Design Verification Methodology
Instruction Behavior In C (Polaris) Micro- architecture in C RT-Level in Verilog Gate-Level Real Mother-board H/W Virtual PC in C language (VPC) C Language Peripherals HDL MCV : Microcode Verifier PLI : Programming Language Interface more refined model MCV FlexPC Virtual Chip Using PLI CPU

Polaris: ISS (Instruction Set Simulator)
ISS for x86 processors : Polaris a standard reference model for the design of x86 processors about 10,000- line code written in C language Polaris can execute all the programs which run on real PC’s Polaris is used for verifying the functionality of each instruction Polaris helps microcode design and debugging with the verified reference model

MCV (Micro-Code Verifier)
DOS simulation window Behavior simulation at micro-operation level Debugging feature trace each micro-operation result operation backward source code trace internal states (registers and buses) symbolic microcode in execution states before executing this microcode can be restored MCV debugging environment

StreC (Structural Level C Model)
RTL Model using C language A cycle is levelized into 4 phases Static scheduling of logic behavior No timing delay Cycle-based simulator High simulation speed(1.4KHz) Structural Analysis of Design Signal Flow Graph Static timing verification Resource estimation at RTL RTL floorplan P1 P1_EDGE P1_LEVEL P2_EDGE P2_LEVEL CP1_EDGE(); DP1_EDGE(); FP1_EDGE(); SP1_EDGE(); KPP1_EDGE(); BP1_EDGE(); XP1_EDGE(); CP1_LEVEL(); DP1_LEVEL(); FP1_LEVEL(); SP1_LEVEL(); KPP1_LEVEL(); BP1_LEVEL(); XP1_LEVEL(); CP2_EDGE(); DP2_EDGE(); FP2_EDGE(); SP2_EDGE(); KPP2_EDGE(); BP2_EDGE(); XP2_EDGE(); XP2_LEVEL_1(); KPP2_LEVEL_1(); CP2_LEVEL_1(); DP2_LEVEL_1(); CP2_LEVEL_2(); FP2_LEVEL_1(); DP2_LEVEL_2(); SP2_LEVEL_1(); FP2_LEVEL_2(); KPP2_LEVEL_2(); BP2_LEVEL_1(); XP2_LEVEL_2();

RTL C Model (StreCTM) RTL description in C Functional Verification
Cycle-based simulation about 100 times speed-up compared to VCS Translated to Verilog RTL model Reducing total simulation time Polaris MCV StreC VCS Chip 210KHz 50KHz 1.4KHz 17Hz 33MHz 20min. 50min. 2days 120days 12sec. speed time time: Windows 3.1 running time Verilog simulation Working Verilog code Functional + timing conversion Conventional Method C model time Functional Static Timing verification StreC Simulation timing C code

VPC (Virtual PC) library
Library of PC chipset model software model of PC board capable of interface to CPU model of any level provides interfaces for workstation platform keyboard, graphic card: X Windows floppy disk, hard disk: UNIX file system C code of 20,000 lines BIOS code mostly consists of x86 assembly program speed-critical part is implemented with C functions disk, graphic routine register values are transferred via I/O port

VPC(Virtual PC) Environment
Chipset model CPU model X window intel i386 BIOS (Assembly and C routine) Interface routines Keyboard with Xlib Memory Debugging feature Simulation & Debugging x86 interface platform interface Virtual PC UNIX file system PC model Platform

HK386 Design Specification Test Programs MS Office
compatibility : Instruction level, Pin-to-Pin compatible with i386 performance : Similar to i386 operation speed : 40 MHz process : 0.8 m DLM CMOS Test Programs MS DOS 6.0, Windows 3.1, Office 4.0 CAD tools, games, etc.. 12 minutes 15 slides (including cover) cover (1) introduction why need? (1) virtual chip concept (1) virtual chip organization (?) experimental result (?) conclusion (1) MS Win. 3.1 MS Office MaxPlus II

HK387 Design specification
compatibility : Instruction level, Pin-to-Pin compatible with i387 operation speed : 33 MHz process : 0.8 m 2LM CMOS performance PC magazine coprocessor benchmark [ops/sec] intel 387 ULSI 387 HK 387 Cyrix 387 AutoCAD R11 Mathematica 3.0 Design Center ...

Saver with ‘Modify and Restart’ Capability
Conventional Saver Dump all running information at arbitrary time points. Any modification forces the simulation to be rewound to the beginning. Proposed Saver Find the nearest suitable points to save snapshot, then save only internal states rather than all simulation context. Can be restarted at any save points by triggering a signal in spite of design modification. 그림 제거 Save point is actively adjusted to a stable point conventional proposed

Reduction of Simulation Time
Simulation Started Timing overhead for a bug-fix Bug Detected Size of debugging loop for failure of bug-fix Signal dump generation for debugging Resimulation from the beginning Without Saver TBD TBD+  TDBG TBD+  Conventional 다시 그림 TBD TSD+ TDBG TBD+  Proposed Saver TBD TSD+ TDBG TSD+ Debugging

x86 Emulation Configuration
Quickturn Hardware Emulator Slow-Down PC Probe Module Target Interface Board

Debugging Progress Traces
HDL saver Attached Windows DOS HDL Simulation Hardware Emulation setup version update 1 update 2 update 3

Catched-Bug Categories
1. Test Program and Random Test Vector are concurrently verified. 2. Exceptional cases of complex instructions are hard to fully verify only with test vectors.

iPROVE add-on’s (cycle and trans mode example)

Transaction-level with C
Step 1: Start with EDIF of the SSRAM – need synthesizer Step 2: make FPGA mapping data Step 3: modify testbench by inserting PLI’s for iPROVE Step 4: run the SSRAM with iPROVE and HDL simulator DUT & transactor goes to iPROVE Testbench runs at host computer

Cycle-level with Verilog
A simple ALU example

Cycle-level with Verilog
Step 1: Start with EDIF of the ALU – need synthesizer Step 2: make FPGA mapping data Step 3: modify testbench by inserting PLI’s for iPROVE Step 4: run the ALU with iPROVE and HDL simulator Testbench runs at host computer DUT goes to iPROVE

Transaction-level with C
A simple SSRAM example PCI DMA controller + FIFO’s

iPROVE Cycle-level Transactor
Automatic generation of cycle-level transactor The iPROVE software analyzes netlist of DUV. iPROVE software automatically generates the transactor. Automatic generation DUV Cycle-level transactor DUV A E A E B F B F C G C G D H D H Proprietary interface (Connected to PCI)

iPROVE Transaction-level Transactor
User designs transactor to transfer data between proprietary interface and DUV Transactor receives data from user application through either C-port or R-port and writes data to W-port. C APIs & PCI DMA controller on iPROVE User’s testbench in C iPROVE API and Device Driver Layer iPROVE PCI Interface Layer Transactor DUV ifp_resetb ifp_clk iwp_clk iwp_cmd_valid iwp_cmd_count iwp_cmd_read iwp_cmd_data CMD BUF CMD FIFO iwp_wr_wrble iwp_wr_count iwp_wr_write WRITE FIFO iwp_wr_data READ BUF iwp_rd_rdble iwp_rd_count iwp_rd_read WRITE BUF READ FIFO iwp_rd_data Proprietary interface is composed of C/R/W-port similar to FIFO interface. Ports of DUV

Sep. 18, 2003/ Portland Hilton Chong-Min Kyung, KAIST

Similar presentations

Presentation on theme: "Sep. 18, 2003/ Portland Hilton Chong-Min Kyung, KAIST"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Sep. 18, 2003/ Portland Hilton Chong-Min Kyung, KAIST

Similar presentations

Presentation on theme: "Sep. 18, 2003/ Portland Hilton Chong-Min Kyung, KAIST"— Presentation transcript:

Similar presentations

About project

Feedback