D e p a r t m e n t

o f
C o m p u t e r
E n g i n e e r i n g
Validation
Establishing that the system does what it was intended to do
Provides confidence in the systems operation
Verification - checking against an accepted entity

generally at higher level

!oC validation

validation of hardware operation

validation of software operation
validation of the combined system operation
!oC - validation - "
# Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Validation

Early phase of !oC design

development of specification
$%& coding
development of behavioral models
'b(ective
to develop a good set of test suites and test cases )including actual software
applications* by the time $%& and functional model are specified
Completeness of testbenches


+bstraction level of various models
!imulation environment
# Peeter Ellervee
!oC - validation - ,
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Core-&evel Validation
Core validation plan
Core specs are verified at behavioral level
-ehavioral model is used as a reference model for other abstraction levels

implementation verification
timing verification
$ecommended

gate-level and layout models for soft and firm cores

silicon prototyping in multiple technologies for hard cores
!oC - validation - .
# Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Validation /ethods at Various +bstraction &evels
+bstraction &evel Core specs !imulation in C0C11
-ehavioral 2D& !ystem simulators 2D& simulators
$egister transfer level 2D& simulators code coverage formal verification
3ate level 4ormal verification gate-level simulators static timing
analysis hardware accelerators emulators
Physical design

Validation /ethod
&ayout vs5 schematics )&V!* design rule checker )D$C*
-oth event and cycle based simulators

event based - small si6es 7 debugging

cycle based - fast for large designs
# Peeter Ellervee
!oC - validation - 8
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
%estbenches

%estbench to verify transactions

bus controllers 7 interface circuits

generation of input stimuli
response checking
%estbench to verify instructions

9!+ models for microprocessors controllers 7 D!P

%estbench for random testing

useful to discover obscure bugs

!oC - validation - :
# Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
%estbenches )cont5*

$egression testbench

identifying specific bugs

%estbench for code coverage

checking for missed function calls unused code etc5

4unctional testbench

testing trough an actual application run

# Peeter Ellervee
!oC - validation - ;
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
!ub--lock %estbenches
Can be limited to input stimuli generation 7 response checking
%he stimuli generators should cover corner cases
"<<= code coverage should be achieved before accepting sub-block for
integration5
Core-&evel 4unctional %estbenches
'ne of the deliverable items
Cosimulation environment can cover only a small fraction of the total
simulation cycles
-us functional model based testbench can cover a sufficiently large number of
simulation cycles
!oC - validation - >
# Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
?!- -us Controller -- -us 4unctional /odel
-us functional
model of ?!- bus
?!- bus
monitor
?!- bus
%estbench
command
file
$%& of ?!- bus
controller
+pplication bus
-us functional model
and bus monitor
# Peeter Ellervee
!oC - validation - @
+pplication domain
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
+pplication
software
Drivers
?!- -us Controller -- 2A0!A Cosimulation
?!- bus
monitor
-us functional
model of ?!- bus
?!- bus
$%& of ?!- bus
controller
!imulation
command
file
+pplication bus
-us functional model
and bus monitor
!oC - validation - B
# Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Core-&evel %iming Verification

!tatic timing analysis is fast but pessimistic in general

false paths
3ate-level simulation is more precise but slow and it takes eCcessive amount of time to
develop stimulus
Different target technologies should be used

/ain benefits of gate-level simulation

verification that the synthesis has generated a correct netlist

verification of timing

verification that the post-synthesis logic insertion i5e5 clock tree buffers scan logic
have not changed the functionality
verification that the manufacturing test are correct
# Peeter Ellervee
!oC - validation - "<
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Core 9nterface Verification

Protocol Verification
-us functional
model of Core +
$%& of core
under test
-us functional
model of Core -
9nterface block
!oC level
global bus
-us functional
model of Core C
-us
monitor
-us controller
!oC - validation - ""
# Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
!oC Design Validation
+ real application run of sufficient length needed
4unctional models of all cores and interfaces are needed
Cosimulation - C0C11 -4/ 9!+
2ardware-only simulation - $%& logic
# Peeter Ellervee
!oC - validation - ",
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Cosimulation
!oftware - C0C11
2ardware - 2D&0$%&

represents the implementation of hardware components

Deeded - one or more 2D& simulators and a C0C11 platform
!ingle simulator - compiled 7 linked
/ultiple simulators - communication

distributed simulators
!oC - validation - ".
# Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Emulation

Cosimulation does not verify implementation

Current emulation technology uses synthesi6ed $%&

a method for checking functional correctness at implementation level

Drawbacks

it essentially validates the behavioral specs of the system

Dot very useful in detecting timing errors
Compilation )synthesis* time after every change
Different design flow from the actual silicon implementation flow
4ast performance only when the entire design can be loaded into the emulation engine
4P3+ based systems and custom systems
# Peeter Ellervee
!oC - validation - "8
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
2ardware Prototypes
Producing a silicon prototype is a costly proposition
%he diminishing bug rate in verification and cosimulation

%he difficulty of finding bugs

4inding a bug may take a few orders of magnitude more time than the time reEuired to fiC it
%he cost )manual effort time-to-market* of finding bugs

Cosimulation and emulation may not be able to run an application for eCtensive time periods to
find )more* bugs
%he search for bugs with the cosimulation or emulation methods may be eCtremely costly
+ set of 4P3+s as prototype
# Peeter Ellervee
!oC - validation - ":