+ All Categories
Home > Documents > Lec2 Introduction

Lec2 Introduction

Date post: 28-Feb-2018
Category:
Upload: gokul-t
View: 230 times
Download: 0 times
Share this document with a friend

of 28

Transcript
  • 7/25/2019 Lec2 Introduction

    1/28

    2011, Meeta Yadav 1

    ASIC VerificationIntroduction to Verification

    Fall 2011

    Meeta Yadav

  • 7/25/2019 Lec2 Introduction

    2/28

    2011, Meeta Yadav 2

    Why do we need Functional Verification?

    Designs are becoming more complex

    Increased functionality increasesthe number of transistors and the

    possibility of error in the design

    The cost of undetected problems grow

    over time

    There is little cost in detecting aproblem during device verification

    but the cost increases substantially

    if the bug is detected by the

    customerVerification Systems

    Test

    Customer

    Time

    C

    ost

    Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier

    The age of digital

    convergence

  • 7/25/2019 Lec2 Introduction

    3/28

    2011, Meeta Yadav 3

    Which is more complex?

    Saturn V moon rocket 45 nm ASIC

    300,000 parts in 70,000assemblies

    1 Billion transistors with ~10 BillionSub-compoments

  • 7/25/2019 Lec2 Introduction

    4/28

    2011, Meeta Yadav 4

    Design Failures: Example

    Pentium floating point bug* (1994) Chip generated inaccurate computations to certain floating point

    calculations

    x= 4195835, y= 3145727, and z=x- (x/y)*y

    gave the answer as 256 instead of 0

    Error occurred due to omission of entries and was hard to detect sinceonly 1 in 9 billion calculations were affected

    Explosion of Ariane 5** rocket (1996)

    Unmanned Ariane 5 rocket of the European Space Agency exploded 40

    seconds after lift-off (Cost $7 billion + $500 million)

    Error in conversion of 64 bit horizontal velocity number to a 16 bit signed

    integer

    * http://www.maa.org/mathland/mathland_5_12.html

    ** http://www.cnn.com/WORLD/9606/04/rocket.explode/

  • 7/25/2019 Lec2 Introduction

    5/28

    2011, Meeta Yadav 55

    IC/ASIC Designs Requiring Re-Spins by Type of Flaw

    0% 20% 40% 60% 80% 100%

    OtherFirmware

    IR Drops

    Power Consumption

    Mixed-Signal Interface

    Slow Path

    Delays/Glitches

    Yield/Reliability

    Fast Path

    Tuning Analog Circuit

    Clocking

    Logic/Functional

    Percent of Designs Requiring Two or More Silicon Spins

    2002 Market Study

    2004 Market Study

    Principle contributors:

    - Functional bugs

    - Clocking related bugs

    [Collet 2005]

    Verification Trends

    50% of ASICS require more than one respin

  • 7/25/2019 Lec2 Introduction

    6/28

    2011, Meeta Yadav 66

    The Verification Challenge

    Two major verification challenges are:

    The challenge of state space explosion

    Formal Verification

    The challenge of detecting incorrect behavior Functional Verification

    Constrained Random Tests

    Coverage

    Assertions

    There are more theoretical

    states in todays design than

    there are atoms in the

    universe!!!

  • 7/25/2019 Lec2 Introduction

    7/282011, Meeta Yadav 7

    Design

    Gap

    Verification

    Gap

    Ability to Verify (Directed)

    Ability to Design

    Ability to Fabricate

    DesignSizeinMillionsofGates

    7

    * Based on data from the Collett International 2004 FV Survey

    The Design & Verification Gap Many companies still using 1990s techniques

    Traditional verification techniques cant keep up with todays designs

    The Verification challenge

  • 7/25/2019 Lec2 Introduction

    8/282011, Meeta Yadav 8

    Traffic Controller

    Design description

    Light should stay green for1 minute in each direction

    when the intersection is

    busy

    Main StreetElmStreet

  • 7/25/2019 Lec2 Introduction

    9/282011, Meeta Yadav 9

    Traffic Controller

    Wait 60

    seconds

    Main St. traffic?

    Elm St. traffic?

    Elm St.

    turns green

    Main St.

    turns green

    yes

    yes

    no

    no

    Algorithm for a Traffic Controller by Eagelton Signal Controllers

    And Parking Engineering Solutions (ESCAPES)

    Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier

    Algorithm Implemented

    Is there a problemwith the design?

  • 7/25/2019 Lec2 Introduction

    10/282011, Meeta Yadav 10

    Functional Verification

    Customer

    requirements

    General

    specification

    and architecture

    High level

    chip design

    HDL

    implementation

    at RTL level

    Functional

    verification

    Physical circuit

    design via

    synthesisFabricated Chip

    Fixes to

    HDL

    Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier

    Goals of Functional verification are to

    ensure The design accurately performs the tasks

    intended by the overall system architecture

    To detect a missing feature

    To detect a missing corner condition

    There are no bugs in the tasksimplemented in the design

    Functional Verification testbenches

    should be built from the general

    specifications and architecture

  • 7/25/2019 Lec2 Introduction

    11/282011, Meeta Yadav 11

    Functional Verification

    Source: Will, Goss, Roesner:

    Comprehensive Functional

    Verification: Elsevier

    Customer

    requirements

    General

    specification

    and architecture

    High levelchip design

    HDL

    implementation

    at RTL level

    Functional

    verification

    Physical circuit

    design via

    synthesisFabricated Chip

    Fixes to

    HDL

    Timing Analysis

    System Testing

    Manufacturing

    Customer

    A well-verified chip reduces cost byavoiding:

    Re-fabrication

    Re-calls

    Design Process

  • 7/25/2019 Lec2 Introduction

    12/282011, Meeta Yadav 1212

    Cost of Bugs

    Verification Systems

    Test

    Customer

    Time

    Cost

    Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier

    The cost of undetected problems grow over time

  • 7/25/2019 Lec2 Introduction

    13/282011, Meeta Yadav 1313

    Verification Productivity

    Time

    Num

    bero

    fBugs

    Source: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier

    Verification productivity reduces cost and schedule

    Verification Systems Test

    Productivity improvements

    drive early problem discovery

  • 7/25/2019 Lec2 Introduction

    14/282011, Meeta Yadav 14

    Overall Testbench Functionality

    Generate stimulus

    Apply stimulus to the Design Under Test (DUT)

    Capture the response

    Check for correctness

    Measure the progress against the overall verification goals

    Design

    Under

    TestStimulus

    Application

    StimulusGene

    ration

    Response

    Capture

    CorrectnessC

    heck

    Golden Model

    Progress Check and Control of

    Verification Process

  • 7/25/2019 Lec2 Introduction

    15/282011, Meeta Yadav 15

    Directed Testing Approach

    Directed Test Progress

    Writing stimulus vectors to exercise various individual features of the design

    Is a time and resource consuming exercise

    Good for small test space with limited variations

    100%

    Time

    Coverage

    Directed

    Test

    Time and resource consuming

    Directed Test Progress

  • 7/25/2019 Lec2 Introduction

    16/282011, Meeta Yadav 16

    Directed Testing Approach

    Directed Testing Coverage Individual test cases cover individual features in the design space

    Over time the entire design space can be covered

    Increase in the complexity of the design causes an increase in the time to

    cover the entire design space

    Directed Test Coverage

    Covered

    Features

    Bug

    UncoveredFeatures

  • 7/25/2019 Lec2 Introduction

    17/282011, Meeta Yadav 17

    Randomization

    Why Randomize? Create VALID corner states : system states of maximum device

    discomfort

    What do you randomize?

    Device Configuration: Move device to states of least probability

    Input data

    Error handling:

    Exception handling by protocols (bus protocols, handshaking, memory

    interface)

    Recovery from errors in system states Relative timing between blocks

    Blocks operating at different rates

  • 7/25/2019 Lec2 Introduction

    18/282011, Meeta Yadav 18

    Stimulus: Constrained Random Testing

    Constrained Random Test Progress Constrain stimulus to VALID limits and allow tool to generate values at random within limits

    Random stimulus is required to exercise a complex design

    Useful in finding unanticipated bugs

    Achieves coverage faster

    Constrained Random Test Progress

    100%

    Time

    Coverage Random

    Test

    Directed

    Test

    More time to writeConstrained random tests

    Less time to achieve

    100% coverage

  • 7/25/2019 Lec2 Introduction

    19/282011, Meeta Yadav 19

    Stimulus: Constrained Random Testing

    Constrained Random Test Coverage Random tests cover wider design space than directed tests

    Tests may overlap

    Directed tests are still needed to test uncovered features

    Constrained-Random Test Coverage

    Directed

    testcase

    Test Overlap

    ? ?

    ?

    New Area

  • 7/25/2019 Lec2 Introduction

    20/28

    2011, Meeta Yadav 20

    Coverage Convergence

    Add

    constraints

    Many runs

    different seeds

    Identify

    holes

    Functional

    Coverage

    Constrained Random

    Tests

    Minimal Code

    Modifications

    Directed

    Tests

    How do we achieve coverage convergence?

    Start with a fully randomizable testbench Run many randomized simulations

    Analyze cumulative coverage and coverage holes

    Then with minimal code changes

    Add constrained stimulus to fill coverage holes

    Finally:

    Make few directed tests to hit the remaining holes

  • 7/25/2019 Lec2 Introduction

    21/28

    2011, Meeta Yadav 21

    Coverage Feedback

    For a large verification space consider coverage feedback

    Time (Code Writing and output

    checking)

    Coverage(%o

    fposs

    iblebugs

    checked)

    Latency for coding

    constrained random tests

    Constrained Random without

    Coverage Feedback

    Constrained Random with

    Coverage Feedback

    Directed tests

  • 7/25/2019 Lec2 Introduction

    22/28

    2011, Meeta Yadav 22

    SystemVerilog Assertions in Verification Strategy

    Assertions:

    1. Captures Designer Intent

    2. Allows protocols to be defined and verified

    3. Reduces time to market

    4. Greatly simplifies the verification of reusable IP

    5. Facilitates functional coverage metrics

  • 7/25/2019 Lec2 Introduction

    23/28

    2011, Meeta Yadav 23

    SystemVerilog Assertions in Verification Strategy

    Time

    Time to Market

    Upfront Cost

    Bugs

    Block Design System Integration

    Ship

    Ship much later with margin of errorShip much

    earlier with less

    risk and cost

    Assertions reduce time to market

  • 7/25/2019 Lec2 Introduction

    24/28

    2011, Meeta Yadav 24

    Writing an Effective Testbench

    Testbench: Emulates the environment of the DUT

    Features of an effective testbench

    Re-usable and easy to modify for different DUTs

    Object-oriented!! Layered: Orthogonalize concerns

    Transactors (encapsulation of protocol) and Interfaces!!!!!

    Catches bugs or achieves coverage quickly

    Randomizable!!

  • 7/25/2019 Lec2 Introduction

    25/28

    2011, Meeta Yadav 25

    Benefits of testbench environment

    Environment updating takes less time

    Testbench is easy to constrain from the top level file

    All Legal Device Configurations are tested

    Regression can select different DUT configurations

    Configuration object is randomized and constrained Enables reuse

  • 7/25/2019 Lec2 Introduction

    26/28

    2011, Meeta Yadav 26

    Levels of Verification

    Memory

    Access unit

    Memory Bus Snoop

    Unit

    DMA Cache ALU FPU

    ProcessorPeripheral Local

    memory

    Board

    Bus

    arbiter

    Memory PCI

    controller

    South

    bridge

    Peripheral

    Backplane Node

    System

    X Y

    Designer

    level

    Unit

    level

    Chip

    level

    Board

    level

    System

    level

    Hierarchical Diagram of Multiple Node System

    Figure Courtesy: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier

  • 7/25/2019 Lec2 Introduction

    27/28

    2011, Meeta Yadav 27

    Levels of Verification and Bugs Detected

    Time

    Bugs

    Designer Unit Chip System

    Lower levels of verification tend to uncover more bugs since they occur earlier

    in the design cycle and because verification of each designer or unit level occurs in

    parallel with the others. It is a good practice to wait until the bug rate begins to drop

    in the low levels before moving to the next level

    Figure Courtesy: Will, Goss, Roesner: Comprehensive Functional Verification: Elsevier

  • 7/25/2019 Lec2 Introduction

    28/28

    Thank You


Recommended