Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Macro Block Verification Techniques: Bottom-Up Testing, Inspection & More, Slides of Computer Science

An overview of macro block verification techniques, including bottom-up testing, inspection, adversarial testing, and more. It covers strategies for functional verification, engineering review, documentation, and various types of verification tests. The document also discusses the differences between verification, validation, and manufacturing testing, as well as fundamental ideas and types of verification tools.

Typology: Slides

2012/2013

Uploaded on 03/22/2013

dhritiman
dhritiman 🇮🇳

4.7

(6)

107 documents

1 / 33

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Verification Techniques for Macro
Blocks (IP)
Overview
Inspection as Verification
Adversarial Testing
Testbench Design
Timing Verification
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21

Partial preview of the text

Download Macro Block Verification Techniques: Bottom-Up Testing, Inspection & More and more Slides Computer Science in PDF only on Docsity!

Verification Techniques for Macro

Blocks (IP)

  • Overview
  • Inspection as Verification
  • Adversarial Testing
  • Testbench Design
  • Timing Verification

Overview of Macro Verification

  • Overall verification plan
  • Strategies
  • Sub-block simulation
  • Macro simulation
  • Prototyping
  • Limited production

Strategy: Bottom Up Testing

  • Verify individual sublocks
    • Focus on coverage of data values and internal states
  • Verify complete macro (block)
    • Focus on interfaces and timing among sub-blocks
    • Test I/O timing and “corner cases”
  • Perform prototyping
    • Proto-board
    • PC board
    • FPGA
    • Platform based design*

Verification vs. Validation

  • In the hardware world:
    • Verification means testing
    • Validation means “formal proof”
  • In the software world:
    • Verification means “formal proof”
    • Validation means testing

Don’t be confused…

Fundamental Ideas

  • Controllability
    • Can you wiggle every wire?
    • Can you set every bit?
  • Observability
    • Can you see the state of every bit?
    • Can you see the value on every wire?

During validation, we can do this in the simulator – especially in a bottom-up mode

(In manufacturing test this is not so easy)

Types of Verification Tests

  • Compliance Testing
    • Against specifications and/or standards
  • Corner Case Testing
    • Try to break the design with complex scenarios
    • “Answer Yes or No [Y]?” > fred
  • Random Testing
    • Use statistical models to generate data patterns
  • Real Code Testing
    • Work with the software team, use real data
  • Regression Testing
    • Keep all tests in a suite and add to them

Verification Tools

  • Simulation
    • functional, cycle, RTL, gate level, circuit level
  • Testbench automation tools
    • Verisity (and others) testing language
  • Code coverage tools
    • Measurements of what got wiggled
  • Hardware Modeling
    • Comparison against / with real hardware
  • Emulation
    • High speed hardware boxes interfaced to simulator
  • Prototyping

“Static” Tools

  • Static timing analysis tools
  • “Lint-like” tools
  • Formal verification tools
    • Model checking
      • Build abstract model of design and environment
      • Uses “smart” exhaustive methods for safety and liveness tests
        • Liveness: something good will eventually happen
        • Safety: nothing bad will ever happen
    • Theorem proving
      • Uses automatic theorem provers to verify assertions about the design

Prototyping

  • Use Prototyping when:
    • You can afford it
      • $cost
      • $time
    • You can not wait for the time it takes to find bugs using available simulation techniques - The prototype is just a fast simulator for the device itself

Adversarial Testing

The designer’s tests have the goal to show that the

system will work…

  • Adversarial Testing uses a verification team of

experts in testing all kinds of designs

  • Goal: develop tests to show that the system will

fail

  • Report failures, and test cases to design team

Testbench

  • The testbench For each component
    • Is the model of its external world
    • Must generate (all) legal input sequences
    • Must check output sequences
    • Must alert the designer and log discrepancies between expected and actual results
  • The testbench is often more complex than

component itself

Sub-block Testbench Design

  • Input transaction data types, sequences
  • Output transaction data types, sequences

Input Transaction Generator

Output Transaction Checker

Device Under Test (DUT)

Assume simple I/O relationships

Output Checking

  • Check for legal sequences of outputs
  • Look at functionality of DUT
  • Check corner cases
  • Check input/output relationships
    • Ideally each sub-block has
      • Simple Functionality
      • Simple I/O

Getting ready for integration

  • Timing checks
    • Timing plan for each sub-block
    • Clocking, handshaking
    • Timing budgets, per-cycle latency budget
  • Area and power checks
    • Are the sub-blocks within their bugets