236605 simulation-based functional contact...

�

236605 – Simulation Based Functional Verification© Original foils by Avi Ziv

236605Simulation-based Functional

Verification

Spring 2008

236605 – Simulation Based Functional Verification �© Original foils by Avi Ziv

Staff

� Lecturer: Moshe Levinger� Contact [email protected]

04-8296179 (Office)� Office hours: Sunday 12:30

(by prior arrangement)

� TA: Amir Nahir� Contact [email protected]� Office hours: Tuesday 18:30

(After the tutorials)

�


Text Book

� Comprehensive Functional Verification: The Complete Industry Cycle by Bruce Wile, John Goss,

Wolfgang RoesnerMorgan Kaufmann Publishing,

May 2005


Other Relevant Books

� Writing Testbenches – Functional Verification of HDL Models (2nd Edition) by Janick Bergeron (Kluwer Academic Publishers)

� Principles of Verifiable RTL Design (2nd Ed.) by Bening and Foster (Kluwer Academic Publishers)

� Design Verification with e, by Palnitkar (Prentice Hall)

� A Practical Introduction to PSLby C. Eisner and D. Fisman (Springer)

� Functional Verification Coverage Measurement and Analysis by A. Piziali (Springer)

�


Grading

� Home Work� Four exercises + one bonus� Mini-project

� Grade� 50% final exam� 30% (+5% bonus) HW exercises� 20% mini-project


Course Main Objectives

� Getting to know Simulation-based verification� Key concepts� Methodologies and strategies� Tools and technologies

� Hands-on experience� VHDL, PSL, Specman ‘e’� Full cycle: planning, implementation, … , bugs

�


Course Outline

� Introduction to functional verification� Verification flow� Verification strategies� Verification plans� Test bench design


Course Outline (continued)

� Stimuli generation� Checking

� Property Specification Language (PSL)

� Coverage� Coverage analysis, regression and bugs� Formal verification� Simulation technologies

�

236605 – Simulation Based Functional Verification © Original foils by Avi Ziv

What Is Verification?

Verification is a process used to demonstrate the correctness of a design w.r.t. the requirements and specifications

� Types of verification� Functional verification� Timing verification� Performance verification


Functional Verification Techniques

� Formal verification� A.k.a. static verification� “Mathematically” prove the correctness of the

implementation

� Simulation-based methods� A.k.a. dynamic verification� Find bugs by executing the implementation and

checking its behavior

�

236605 – Simulation Based Functional Verification ��© Original foils by Avi Ziv

Some Terminology

� In the hardware world:� Testing means manufacturing testing� Verification means “comparing design to spec”

� Can be static or dynamic

� Validation means “formal proof”� In the software world:

� Verification means “formal proof”� Testing means “dynamic verification”

Don’t be confused…


Chip Design ProcessGeneral

Specification and Architecture

High Level Chip Design

HDL Implementation(Logic Design)at RTL Level

Physical Circuit Design via Synthesis

Or Custom Layout Design sentTo Fab

Customer Requirements

FabricatedChip

Functional VerificationFixes To HDL

High Level Verification

� �

�

�


Nightmare on Elm Street

� Problem: Traffic congestion in the intersection of Main and Elm streets

� Solution Requirements: Install traffic lights in the intersection to allow fair flow of traffic in all directions

� Specification: A careful study of the traffic survey leads the council to specify that the light should stay green for one minute in each direction when the intersection is busy. Workers are to install sensors to detect traffic on both Elm and Main streets


Nightmare on Elm StreetWhat do we want to check?

�


Nightmare on Elm Street Low-level implementation

Elm_Street

reset

timer_pulse

Main_Street

clk

Light_Direction(o)

Light_Direction(1)

reg_proclatch


Nightmare on Elm Street High-level implementation

Main StreetTraffic?

Elm Streetturns green

Main Streetturns green

Wait 60 seconds

Elm StreetTraffic?

Yes

YesNo

No


What is wrong with the algorithm?


Uncovering The Problem

� Formal tool: “Prove that if cars are waiting at Elm St., its light will become green within reasonable time”� The formal tool will provide a scenario that

violates this property

� Dynamic tool needs to verify that this property is not violated during simulation� To detect the problem, the correct scenario must

be used

�


Fixing The Problem

� Change the priority of Main and Elm according to � Static policy� Past states

� The simplest solution – use turn flag� Switch priorities every time the light changes


The Verification Challenges

� Hardware designs are large and complex� Extremely parallel� Implement complex algorithms� Non-functional requirements make the design even more

complex� Execution speed is very slow (compared to HW

speed)� Design size and complexity increases faster than

tools capabilities� High cost for late detection of bugs

� In the lab means delay of several weeks in delivery� In the field means huge cost for replacement

��



� How do we know that a design is correct?� How do we know that the design behaves as

expected?� How do we know we have checked

everything?



In simplest terms, the verification challenge comes down to two fundamentals:

1. Drive the state transitions and input scenarios2. Flag any incorrect behavior exhibited by the

design

��


Detecting Incorrect Behavior

How do we know if a pixel is wrong?

Does the video appear correctly on a monitor?

Streaming-encodedvideo

Digital Video Converter

Is system-wide coherency maintained?

Is the correct dataretrieved and stored?

Requests for data and store commands frommultiple processors to a large array space

Memory Controller

Can the device handle hundreds of possible traffic generation sources?

Does the proper data move to the correct outbound port?

Header data followed by destination, data, CRC

IO Device

Have all possible instr. combination been verified

Do the registers have the correct values

Instruction stream loaded into memoryMicroprocessor

Special challengesExample of result validation

Functional-based stimulusType of design


An expanded look at the design process

Fabricated Chip

GeneralSpecification and

Architecture

High Level Chip Design

HDL Implementation(Logic Design)at RTL Level

Physical Circuit Design via Synthesis

Or Custom LayoutDesign sentTo Fab

Customer Requirements

System Testing

Manufacturing

Customer

Functional Verification��

High Level Verification

��


Cost of Bugs Over Time

� The longer a bug goes undetected, the more expensive the fix� A bug found early (designer sim) has little cost� Finding a bug at Chip or System Sim has moderate cost� Finding a bug at the lab (test-floor) requires new tape-out

� Cost of tape-out can be millions of Dollars� Delay of weeks in delivery

� Finding a bug in the field (customer's environment) can cost hundreds of millions in hardware and brand image

� E.g., Intel’s Pentium Floating-Point bug (1993)


Cost of Bugs Over Time

Verification Systems Test Customer

Cost

Time

��


Increasing Verification Productivity

Time

Numberof Bugs

Systems Test

Verification

Productivity improvements driveearly problem discovery


The Verification Cycle

Functional Specification

Designer ImplementsThe functional specification

(in HDL)

CreateVerification

PlanDevelop

Verification Environment

Stimulus, checkers,Formal Verification

Debug HDL andEnvironment

Run Regression

Perform EscapeAnalysis

Debug FabricatedHardware

Lesson Learned

Tape Out Readiness

Plan Review

��


Functional Specifications

� The functional specification describes the desired product

� It contains the specification of:� The function that it must perform� The interfaces with which it communicates� The conditions that affect the design.

� Designers implement the specification in HDL� Verification engineers incorporate the functional

specification into the verification plan and environment.� This may seem redundant, but it is the foundation of

verification.


Create Verification Plan

� Functions to be verified: list the functions that will be verified at this level of verification.� Functions not covered: any functions that must be verified at a

different level of the hierarchy. � Resources required (people, hardware and software) and

schedule details: tie the plan to the program management by estimating the cost of verification.

� Required tools: list the software necessary to support the described environment. (Chapter 5-6)

� Specific tests and methods: define the type of environment that the verification engineers will create. (Chapters 3-4,7-12)

� Completion criteria: Define the measurements that indicate that verification is complete (Chapter 13)

��


Develop Verification Environment

The verification environment is the set of software code and tools that enable the verification engineer to identify flaws in the design. The software code tends to be specific to the design, while the tools are more generic and are used across multiple verification projects

� Major components in the verification environment are stimulus and checking for simulation based environments, and rules generation for formal verification environments

� The environment is continually refined throughout the verification cycle � Refinements include fixes and additions to the software code


Debug HDL and Environment

� Run tests according to the verification plan and look for anomalies

� Examine the anomalies to reveal the failure source� Can be either in the verification environment or in the

HDL design� Fix the cause of the failure

� Either the verification environment or the HDL design� Once the problem is fixed, rerun the exact same test

� This ensures that the update corrects the original anomaly and does not introduce new ones

� Update the verification plan based on lessons learnt

��


Run Regression

� Regression is the continuous running of the tests defined in the verification plan

� Often, verification teams leverage large workstation pools, or “farms”, to run an ever-increasing number of verification jobs

� Regression is used to uncover hard-to-find bugs and ensure that the quality of the design keeps improving

� With chip fabrication on the horizon, the verification team must reflect on the environment to ensure that they have applied all valid scenarios to the design and performed all pertinent checks� This is the tape-out readiness checkpoint.


Debug Fabricated Hardware

� The design team releases the hardware to the fabrication facility when they meet all fabrication criteria� This process is also known as the tape-out

� The design team receives the hardware once the chip fabrication completes

� The hardware is then mounted on test vehicles or into the planned systems for these chips

� The hardware debug team performs the “hardware bring-up”� During hardware bring-up, further anomalies may present

themselves.

��


Perform Escape Analysis

� Analysis of bugs that were found later than when they should have

� The goal is to fully understand the bug, as well as the reasons that it went undiscovered by the verification environments

� An important goal is to reproduce the bug in a simulation environment, if possible� The lack of reproduction in the verification environment

indicates that the design team may not understand the bug

� It would then follow that the team cannot assert that the bug fix is correct without reproducing the original bug in verification.


Common Verification Breakdowns

� Verification based on the design itself instead of the specification

� Underdeveloped verification plans� Underdeveloped specifications� Lack of resources� Tape-out based on schedule instead of pre-

defined measures

�


Summary

� Functional verification is a necessary step in the development of today’s complex digital designs

� Verification engineers must understand the specification and internal microarchitecture of the design under verification� They couple this knowledge with programming skills, RTL comprehension, and

a detective’s ability to find the scenarios that uncover bugs.

� The two main challenges in the verification process:� Creation of a comprehensive set of stimulus� Identify incorrect behavior when encountered

� The foundation for a successful verification is the well-defined verification cycle� The process includes creation of test plans, writing and running verification

tests, debugging, and analysis of the holes in the verification environments

236605 simulation-based functional contact...

Documents