Chapter 11 System-Level Verification Issues

The Importance of Verification

Verifying at the system level is the last opportunity to find errors before the design is committed to silicon

For many teams, Verification takes 50 to 80% of the overall design effort

For SoC design, verification must be an integral part of the design process from the start and it cannot be an afterthought to the design process

Successful system-level verification factors Quality of the verification plan Quality and abstraction level of the of the models and testbenc

hs used Quality and performance of the verification tools Robustness of the individual predesigned blocks

The Verification Strategy

Divide-and-conquer approach Verify that the leaf nodes of the design

hierarchy are functionally correct as stand-alone units

Verify that the interfaces between blocks are functionally correct

Run a set of increasingly complex applications on the full chip

Prototype the full chip and run a full set of application s/w for final verification

Decide when it is appropriate to release the chip to production

Block Level Verification

For large SoC designs, block-level verification is prerequisite

Bugs are much easier to find at the block level rather than chip level

Exception to block level verification The design team may well decide not to produce prot

otypes of single-use blocks before they are integrated into the chip

The first version of the chip must be considered a prototype.

Interface Verification

Chip verification with interface verification Knowing that the individual blocks have been

robustly verified, chip-level verification consists of verifying the interfaces and interaction between the blocks

Inter-block interfaces usually have a regular structure

Transaction Verification Data and Behavioral Verification Standardized Interfaces

Transaction verifiaction

Transaction types that can occur at each interface and testing each one.

A simple, Regular communication architecture between blocks can reduce the system verification effort

Transaction checking Bus monitor : coded behaviorally and provide very go

od simulation performance. Observability, controllability

Point-to-point interfaces : build some simple transaction checking into the interface module of each block

Block1Block1

RTLInterface

Block1RTL

Interface Block2

Block2RTL

Interface

Block2RTL

Interface

Block3Block3

RTLInterface

Block3RTL

Interface Block4

Block4RTL

Interface

Block4RTL

Interface

System verification using interface testing

Block4

Block1 RTLInterface

Block4

Block1 RTLInterface

BusTransaction

Monitor

Block4

Block1 RTLInterface

Block4

Block1 RTLInterface

Data or Behavioral Verification

It is necessary to verify that the block behaves correctly for all values of data but it is impossible

We can construct test cases either from our knowledge of the system of by random generation

Data sequences that the designer expected the block to receive can occur in the actual system to which the block does not respond correctly

Another method for dealing with the problem is to design a checker into the block interface itself.

This approach bas been used effectively in high-reliability system designs.

Functional Verification(1)

The ultimate goal of this aspect of verification is to try to test the system as it will actually be used.

However, conventional simulation is simply not fast enough to execute the millions of vectors required to run even the smallest fragments of application code

Two basic approaches to addressing this problem Increase the level of abstraction Use specialized hardware for performing

verification

Canonical SoC Design

PROCESSOR

PERIPHERALS

MEMORYCONTROLLER MEMORY

I/OINTERFACE

DATATRANSFORMATION

I/OINTERFACE

SYSTEM BUS

Functional Verification(2)

The key features of the verification environment The full RTL model is used as the simulation model for

most of the functional blocks Behavioral of ISA models may be used for memory and

the microprocessor Bus functional models and monitors are used to

generate and check transaction with the communication block

It is possible to generate real application code for the processor and run it on the simulation model

Behavioral models are now substituted for the memory and microprocessor

Using C/C++ models for both the processor and memory dramatically improves simulation speed over full RTL simulation

System verification environment

CommunicationBus functional

Model(RTL)

SequenceGenerator/analyzer

CommunicationBus functional

Model(RTL)

I/O Interface(RTL)

DataTransformation

(RTL)I/O Interface

(RTL)

BusMonitor

Application software/Drivers/RTOS Complier

RTL interface RTL interface

MemoryC/C++

OtherPeripherals

(RTL)

ProcessorC/C++

ProcessorC/C++

CHIP

Application-Based Verification

About 90% of ASIC designs work right the first time, although only about 50% work right the first time in the system because most ASIC design teams do not do system-level simulation

Running significant amounts of real application code is the only way to reach this level of confidence in an SoC design.

The available options for rapid prototyping include FPGA or LPGA prototyping Emulation-based testing Real silicon prototyping

FPGA and LPGA Prototyping

For small designs FPGA

Reprogrammable Allowing rapid turnaround of bug fixes

LPGA higher gate counts Faster clock speed

For prototype of a single large chip Use multiple FPGAs to build a prototype But it is impossible to modify quickly when a bug fix r

equires repartitioning of the design between devices

Emulation Based Testing

A better alternative to using a collection of FPGAs for rapid prototyping of large chips Programmable interconnect Fixed board design Relatively large gate counts Special memory Processor support

Emulation can provide excellent performance for large-chip verification if the entire design can be placed in the emulation engine itself

Silicon Prototyping

If an Soc Design is too large for upper cases then building a real silicon prototype may be the best option.

Reasonable set of criteria The bug rate form simulation testing should have peaked and be

on its way down. The time to determine that a bug exists should be much greater

than the time to fix it The cost of fabricating and testing the chip is on the same order The scenario we want to avoid is building a prototyping only to

find a critical bug that prevents any useful debug of the prototype Help facilitate debug of this initial prototype

Good debug structures for controlling and observing the system The ability to selectively rest individual blocks in the design The ability to selectively disable various blocks to prevent bugs in

these blocks form affecting operation of the rest of the system

Gate-Level Verification

The final gate-level netlist must be verified for both correct functionality and for timing

Sign-Off Simulation Formal Verification Gate-Level Simulation with Unit-Delay Timing Gate-Level Simulation with Full timing

Sign-Off Simulation(1)

RTL sign-off, where no gate-level simulation is performed, is becoming increasingly common.

Problems Full timing simulation of million-gate ASIC is not possible with o

ut very expensive H/W accelerators, and it is very slow Parallel vectors have very low fault coverage Parallel vectors do not exercise all the critical timing paths

Different paradigm Verification that synthesis has generated a correct netlist and t

hat subseqeunt operations such as scan and clock insertion have not changed circuit functionality

Verification that the chip, when fabricated, will meet timing A manufacturing test that verifies that the chip is free of manuf

acturing defects

Sign-Off Simulation(2)

The Current methodology uses separate approaches to address each issue Formal verification is used to verify correspondence

between the RTL and final netlist Static timing analysis is used to verify timing Some gate-level simulation, either unit-delay or full ti

ming, is used to complement formal verification and static timing analysis

Full scan plus BIST provides a complete manufacturing test for functionlity.

Formal Verification

Formal verification uses mathematical techniques to prove the equivalence of two representations of the circuit

To check equivalence between the original RTL The synthesized netlist The netlist after test logic is inserted The netlist after clock tree insertion and layout. Hand edits

Benefit of formal verification Allows the RTL to remain the golden refrence for the design, reg

ardless of modifications made to the final netlist

Gate-Level Simulation with Unit-Delay Timing

Unit-delay simulation involves performing gate-level simulation with unit delay for each gate.

Unit-delay simulations can be used to verify The chip initializes properly The gate implementation functionally matches the RTL descripti

on Gate simulation complements formal verification Gate simulation is important for verifying initialization bec

ause gate-level simulation handles propagation of unknown or uninitialized states more accurately than RTL simulation

Gate-Level Simulation with Full timing

Full-timing simulation on large chips is very slow

Used only where absolutely necessary This technique is useful for validating

asynchronous logic Embedded asynchronous RAM interfaces single-cycle timing exceptions

These tests should be run with the back-annotated timing information from the place and route tools, and run with hazards enabled.