15 1 Design Verification(1)

8/19/2019 15 1 Design Verification(1)

1/63

Design Verification


2/63

2

Verification Costs

~ 70% of project development cycle:design verification

− Every approach to reduce this time has a considerable

influence on economic success of a product.

Not unusual for ~comple chip to go

through multiple tape!outs before

release.


3/63

3

"roblems found on #st spin $s&'($s

43%

20%

17%14%

12%

11%

11%

10%

10% 7% 4% 3% Functional Logic Error

Analog Tuning IssueSignal Integrity Issue

Clock Scheme ErrorReliability Issue

Uses Too

Much Power

Mixed Signal Problem

Has Path Too Slow

Has Path Too FastIR Drop Issues

Firmware Error

Other Problem

Source: DeepChip, Aart de Geus, Chairman & CEO of Synopsys used

it during Wed, 10 Sep 2003 Boston SNUG keynote address

Overall 61% of New ICs/ASICs Require At Least One Re-Spin

%3 !ue to fun"tional error


4/63

Importance of Verification

) Verification is a bottleneck in the design process:

*igh cost of design debug− designers +sometimes verification engineers , - design engineers/

− time!to!maret

*igh cost of faulty designs +loss of life1 product recall/


5/63

#

French Guyana, June 4, 1996

$800 million software failure


6/63

6

Mars, December , 1999

!rashe" "ue to uninitiali#e"ariable


7/63$

$4 billion "eelo%ment e&ort

' (0) system inte*ration + ali"ation cost


8/63

400 horses

100micro%rocessors


9/63&

Types of Errors

1. Error in specificationa/ 2nspecified functionality1

b/ onflicting re3uirements1

c/ 2nreali4ed features.

) 5he 6nly (olution: edundancy) because specification is at the top of abstraction hierarchy

No reference model to chec

2. Error in implementation


10/631'

Types of Errors

2. Error in implementation: e.g. human error in interpreting design

functionality.

) Soltion 1:

2se soft8are program to synthesi4e animplementation directly from specification.

− Eliminates most human errors1

− Errors remain from

#.9ugs in synthesis program1

-.2sage errors of synthesis program.


11/6311

Error in implementation

) Soltion 1 !cont"d#: 2se of synthesis tools are limited because:

#.any specifications are in conversational language

− 'utomatic synthesis not possible yet1

−No high level formal language specifies both functionality and timing

+or other re3uirements/ yet.-.Even if specifications are 8ritten in precise mathematical

language1 fe8 soft8are can produce implementations that

meet all re3uirements.


12/6312


) Soltion 2 !more $idely sed#: %nco&er throgh

redndancy:

$mplement t8o or more times using different

approaches and compare.

$n theory: the more times and more different

8ays: *igher confidence.

$n practice: rarely ; -1 because of − cost1

− time1

−more errors can be introduced in each alternative.

5o mae the t8o approaches different:− 2se different languages:

− (pecification


13/6313


)In soltion 2: (ometimes comparison is hard:

− E.g. ompare t8o net8ors 8ith arrival pacets that may be

out of order.

− (olution: (ort the pacets in a predefined 8ay.

(olution - is double!edge s8ord:− =erification engineers have to debug more errors +in design

and verification language/.

− high cost.

− =erification engineers may involve 8ith the differences

inherent to the languages +e.g parallelism in /

− *int: 9e a8are of these differences.


14/631

'nctional Verification

) T$o Categories:#. (imulation!9ased =erification1

-. @ormal ethod!9ased =erification

>ifference in the eistence or absence of input vectors.


15/631#


) Simlation ( dynamic ? 5he most 8idely used

? 5he only solution for system verification

A >evelop testbench and tests A *ard to understand coverage&completeness

) 'ormal ( static ? Ehaustive A good for module&bloc

A


16/631$

Verification and Test

) Verification

Ensuring that the design matches the designerBsintent&specification

>etection of design errors accidentally made by the designer+s/ 2sually includes the debugging tas as 8ell

) !)anfactring# Test

>etection of physical defects in the implementation

>efects appear as a result of manufacturing or of 8earmechanisms

5ests the fabricated product1 not the design


17/63

1


) Simlation(*ased Verification

>irected

andom

) 'ormal Verification

odel checing

E3uivalence checing

5heorem proving

) +ssertion(*ased Verification

>ynamic formal verification


18/63

1&

Verification )etrics

) ,ality of a simlation on a design:

'nctional Co&erage: % of functionality verified

Code Co&erage: % of code simulated− % of statements1

− % of branches taen.


19/63

2'

'lo$ of Simlation(*ased Verification

!esi(n

test)en"*

!esi(n

si+ulation

!e)u(

re(ression

revision

"ontrol

)u( tra",in("overa(e

+etri"s

sti+ulus

(eneration

test plan lintin(

) >ashed line: omponents

specific to sim!based

methodology +are replaced

by components in formal

methodology/


20/63

21


) -inter:hecs for static errors or potential

errors and coding style guideline

violations.− (tatic errors: Errors that do not re3uire input vectors.

− E.g.

− ' bus 8ithout driver1

− mismatch of port 8idth in module definition and instantiation.

−dangling input of a gate.


21/63

22


) *g Tracking System:

Chen a bug found1 it is logged into a bugtracing system

$t sends a notification to the designer. @our (tages:

#. 6pened:− 9ug is opened 8hen it is filed.-. =erified:

− 8hen designer confirms that it is a bug.

D. @ied:− 8hen it is destroyed.

. losed:− 8hen everything 8ors 8ith the fi.

95( allo8s the project manager toprioriti4e bugs and estimate projectprogress better.


22/63

23


) egression:eturn to the normal state.

− Ne8 features ? bug fies are made available to the

team.


23/63

2


) e&ision Control:Chen multiple users accessing the

same data1 data loss may result.− e.g. trying to 8rite to the same file simultaneously.

"revent multiple 8rites.


24/63

2#

Simlation(*ased Verification( classified by inpt pattern

) Deterministic/direct testing

traditional1 simple test input

) andom pattern generation

8ithin intelligent testbench automation

) Dynamic !semi(formal#

8ith assertion chec

) 0attern generated from +T0 !+to. Test 0attern eneration# academic only


25/63

26

Deterministic testing

)ost common test methodology sed today De&eloped manally and normally correspond directly to the

fnctional test plan.

Specific seences that case the de&ice to enter e3treme

operational modes.

Dra$backs:

− Time(consming4 manal programming effort.

− Difficlt to think of all reired &erification cases.

− maintenance effort is high.

56 se random7


26/63

2

+tomated Verification

) +tomatic random generation of inpts

) +tomatic checking of the reslts !a mst#

(aves manual effort of choosing values

$mproves test coverage

0#00##

###000

0#0#0#

#00#0#DUT

andom

0attern

enerator

andom

0attern

enerator

+tomatic

Checker

+tomatic

Checker


27/63

2&

'nctional &erification approaches

( *lack *o3 4 8hite *o3 9

) *lack bo3:

Cithout any idea of internal implementation ofdesign

Cithout direct access to the internal signals

) 8hite bo3:

*as full controllability and visibility on internal

structureE.g. 6bserve internal registers in a microprocessor

) ray bo3:

ompromise in bet8een


28/63

3'

*lack *o3 Testing

5esting 8ithout no8ledge of the internals of the design.

6nly no8 system inputs&outputs

5esting the functionality 8ithout considering implementation

$nherently top!do8n


29/63

31

*lack *o3 Testing E3amples

) E3amples:

5est a multiplier by supplying random

numbers to multiply

5est a braing system by hitting the braes at

different speeds

5est a traffic light controller by simulating pre!

recorded traffic patterns


30/63

32

*lack *o34 8hite *o39

) ecommendation by e3perience:

) Start $ith a black bo3 approach

Food for early testing 8ith behavioral models and architectural eploration

ay develop the testbench scheme earlier

ore reusable +fleible/ in the future) -ater4 add more $hite(bo3 pieces

e3uire to involve the designersG

) E3tra tests sing $hite bo3; approach is necessary

Hblac boI test spec are insufficient to reach the structural coverage target

looing at the coverage holes and specifying specific transaction se3uences

that need to be performed in order to hit the previously uncovered holes.

) ray bo3 is sally sggested


31/63


32/63

3$

Verilog

) Continos +ssignment:

"ropagates inputs to outputs 8henever inputs change

+concurrent assignment/.

always@(posedge c or d)

begin

v = c + d + e;

w = m – n;

…

end;

) 0rocedral *lock:

assign v = x + y + z;


33/63

3

Verilog

)


34/63

3&

Coding for Verification

5he best 8ay to reduce bugs in a design is to minimi4e

the opportunities that bugs can be introduced +i.e.

design 8ith verification in mind/− 6nce this is achieved1 the HnetI step may be to maimi4e the

simulation speed.− because the benefits of minimi4ing bug!introducing opportunities far out8eigh the

potential lost code efficiency.


35/63

'

Coding idelines

) Coding idelines Categories:

#. @unctional correctness rules:− (tate eplicitly the coding intent eliminate the hidden side effects of some

constructs.− E.g. atching 8idth for all operands

-. 5iming correctness rules:

− Eamine code that may cause race1 glitches and other timing problems.

D. "ortability and maintainability rules:− Enforce partition and structure1 naming convention1 comments1 file organi4ation1

J.

. (imulation performance rules:− ecommend styles that yield faster simulation.

K. 5ool compatibility rules:− Ensure the code is acceptable by other tools +e.g. synthesi4ability1 debugability/


36/63

1

Coding idelines

) -inter:

2sed to chec syntactical errors1

9ut as people reali4ed that many design errors can be

checed statically1 their role has epanded to coding

styles

− Need no input vectors− =*>< linters are more po8erful +=erilog allo8s more freedom to

designer/.


37/63

2

'nctional Correctness

) T$o categories:

(yntactical checs:− an be analy4ed locally.

− E.g. une3ual 8idth operands.

(tructural checs:− ust be done globally +i.e. the structure of circuit must be

checed/

− E.g. combinational loops.


38/63

3

Syntactical Checks

) Common syntactical rles:

#. 6perands of une3ual 8idth:− ost *>


39/63

Syntactical Checks

) Common syntactical rles !contined#:

D. 6verlapping condition cases:− (ynthesis tool may produce a priority encoder +8ith higher priority to

(9/

− 9ut designer may not mean that +e.g. 8ants 0 to be assigned if ( ,

#0#/

case (*)

b",, = "b";

b,," = "b!;

endcase;

− 'void overlapping conditions.


40/63

#

Syntactical Checks

) Common syntactical rles !contined#:

. onnection rules:− 2se eplicit connections +i.e. named association/.


41/63

6

Strctral Checks

) Common strctral rles:#. 'void combination loops

-. 'void latch loops +@ig -.M/ *arder to discover because needs to determine 8hether all latches in

the loop can become transparent at the same time:

omputationally intensive.

designer assist the checer by telling him&her about the phases of

latch clocs.


42/63

$

Strctral Checks

) Common strctral rles !contined#:

D. 9us 6peration: >rivers must be checed for mutual eclusion of their enable signals.

@= method: computationally epensive

(imulation: partial validation +data dependent/

. @@ and


43/63

Timing Correctness

ontrary to common belief1 timing correctness1 to a

certain degree1 can be verified statically in the 5<

8ithout physical design parameters +e.g.

gate&interconnect delays/.


44/63

&

Timing Correctness

) ace 0roblem:

Chen several operations operate on the same entity +e.g.variable or net/ at the same time.

Etremely hard to trace from $&6 behavior +because non!deterministic/

Eample #:

always @(posedge clock)x = "b";

always @(posedge clock)

x = "b!;

Eample - +event counting/:

always @(x or y) even'-n.mber = even'-n.mber + ";

− $f and y have transitions at the same time1 increment by one or t8o− (imulator!dependent


45/63

#'

Timing Correctness

) Clock aing:

an produce glitches on cloc tree

− trigger latches and @@s falsely.

(olution #:− 'dd delay to here

"roblems:

#. *ard to control the delay +depends on physical design/.-. Oero!delay simulations still produce the glitch.

9etter (olution:− 2se 6 as the gating device:

− cloc goes to high first and stabili4es the output of 6.

− $f the gating @@ is negative!edge triggered1 should use 'N>.

Q

Q(E5

%

Q

Q(E5

%

cloc0


46/63

#1

Timing Correctness

) Time =ero litches:

Puestion: 't the start of simulation1 8hen a cloc is

assigned to #1 should the transition from L +unno8n/to # be counted as a transition

− 'ns8er: depends on the simulator.

(olution: >elay assignment to cloc to avoid

transitions at time 4ero.


47/63

#2

Simlation 0erformance

1. >igher -e&el of +bstraction:

) 9ehavioral level is much faster than structural gate

level.

2. Simlator ecogni?able Components:

) any simulators attempt to recogni4e some standard

components +e.g. @@s1 latches1 memory arrays/ tomae internal optimi4ation for performance.

) >epends on the simulator efer to user manual to conform to the recommended style.

) $f no such recommendation is provided:) ode in a style as simple and as close to the HcommonI style as

possible:


48/63

#3


) ommon styles:

%% posi'ive&edge&'riggered /00

always @(posedge clock)

1


49/63

#


@. 'S)s:

) "articular styles are preferred by the simulator.

) Feneral rule of thumb:) (eparate as much combinational logic from the states as possible.

A. Vector &s. Scalar:

) Chenever possible1 use the entire bus as an operand+instead of bits/) 9ecause simulators tae more internal operations to access bits or

ranges of bits.

) onvert bit operations into bus operations by:

) oncatenation1 reduction1 and masing.


50/63

##


onvert scalar operations to vectored operations:

assign b.s6"7!88 = a 9 b;

assign b.s6"":8 = x y;

− (calar 6peration:

assign b.s = x y a 9 b>; %% > is conca'

− =ectored 6peration:

assign o.'p.' = (b.s6"8 9 b.s68) (b.s68 ? b.s6!8);


assign o.'p.' = (9(b"!!" b.s)) (?(b"!!" 9 b.s))



51/63

#6


2seful application: Error orrection ode

C = A[0] ^ A[1] ^ A[2] ^ A[9] ^ A[10] ^ A[15];


C = ^(A & 16’b1000011000000111);


FOR (i=0; i


52/63

#$


=ectori4ation in instantiation of arrays of gates− (imulator recogni4es the inherent bus structure.

Fi!F"! FFs [31#0] ($%("'!') $(in!') $*"*(*"*));

− Fenerates D- @@s 8ith inputs that are connected to bus >1 output bus

P and a cloc.


53/63

#


B. )inimi?e interface to other simlation systems:

) 'void displaying or dumping too much data on the

host during run!time speedup by a factor of #0 or more.

>isplay or dump code should be able to turn on&off

) (hould be turned on only during debug mode.


54/63

#&


. Code 0rofiler:

' program attached to simulator 8hich collects about

the distribution of simulation time

2ser determines the bottlenecs of the simulation:

E.g. the total time spent on the simulation of

− a particular instance1− a particular boc +such as a,a-s/1

− a particular function1

− J.

odel(im: "erformance 'naly4er


55/63

6'

0ortability and )aintainability

' design team must have a uniform style guideline so

that the code is easy to maintain and reuse .− Note: ode may range from thousands to millions.

) Top do$n approach:

"roject!8ide file structure1

ommon code resources1

$ndividual file format.


56/63

61


1. 0roect Code -ayot

orrespondence bet8een file structure and top!do8n

functional blocs:

1

2

3

Sour"e .ire"tor0

ol!er 1 ol!er 2

ol!er 3

ol!er

Each file should contain only one module− Ecept for cell library.


57/63

62


5op!level module should consist only of module

instantiation and interconnects− No logic

− eason: top module represents a partition of the design all lo8!level logic

should belong to one of the functional blocs.

inimi4e the number of models of a module +behavioral for

fast simulation1 structural for easy synthesis1 J/:− $f there are more than one model coeists in a file1 e3uivalence must be

ensured.

− aintaining multiple!models and their e3uivalence has a high cost later in the

project.

− 6ther models should eist only in the cell library or macro library +not in the

5< files/.


58/63

63


*ierarchical path access should be permitted only intestbenches +all accesses must be done through ports/− *ierarchical path access enables reading&8riting to a signal directly over a

design hierarchy 8&o going through ports.

− (ometimes is necessary in testbenches because the signal monitored may

not be accessible through ports.


59/63

6


2. Centrali?ed esorces:

' project should have a minimum set of common

sources:#. a cell library and

-. a set of macro definitions

'll designers must instantiate gates from the project

library +instead of creating their o8n/

'll designers must derive memory arrays from the

macro library.

No global variables are allo8ed.


60/63

6#


@. T- Design 'ile 'ormat:

Each file should contain only one module

5he filename should match the module name.

5he beginning is about the designer and the design:− Name1

− >ate of creation1− ' description of the module1

− evision history.

Net: header file inclusion.

$n port declaration1 brief description about the ports1


61/63

66


Each begin!and!end pair should have marers to

identify the pair.

begin %% s'ar' o5 searc2

333

begin %% 5o.nd i'

333

end %% end o5 5o.nd i'333

end %% end o5 searc2

Naming convention:− cQbus8idth1 vQinde1 sQsig#1 J.


62/63

6$


Each begin!and!end pair should have marers to

identify the pair.

begin %% s'ar' o5 searc2

333

begin %% 5o.nd i'

333

end %% end o5 5o.nd i'333

end %% end o5 searc2

Naming convention:− cQbus8idth1 vQinde1 sQsig#1 J.

f


63/63

eferences

#. >. esign =erification: (imulation

and @ormal ethod!9ased 'pproaches1I "rentice!*all1 -00K.

-. >. Fajsi and (. 'bdi1 R(ystem >ebugging and

=erification: ' Ne8 hallenge1R =erify -00D1 5oyo1Sapan1 November -01 -00D.

D. (lides from H*igh esign =erification ! urrent

=erification 5echni3ues T 5oolsI by hia!Uuan 2ang

15 1 Design Verification(1)

Documents

Transcript of 15 1 Design Verification(1)