Introduction To Specman and The: e Programming Language

Introduction to Specman and the
e programming language
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

Specman (Elite) & e
Developed by Verisity
Verisity was bought by Cadence 04/2005
Has over 50% market share
Specman is the tool/compiler/debugger for e
There are e constructs to control Specman’s
parameters
I don’t hate e
But I will try to show some of its weaknesses…

One more thing before we start…
Specman is a tool in-use, and as such, it is being
changed and updated (and hopefully improved) all
the time
One of the latest versions includes a new generator
called ‘inteligen’
What we’ll study is true for version ~4.2.1
The lab has 5.0.3
The methodology, and most guidelines, are
version-independent anyway…
Specman & e (cont.)
e was designed for the development of
verification environments
Coverage
Checking
Constraint based generation
Temporal elements
Resembles “normal” programming languages,
with unique features for the purpose of
verification
The difference between e and
“normal” programming languages
e looks like a programming language which
combines OOP and AOP
‘like’ & ‘when’ inheritance, polymorphism
Encapsulation (starting version 4.1)
Which can be easily violated
Focus on verification-oriented features
Randomness
Awareness to simulation time, temporal expressions
Easy access to the DUV

The Simulation Environment

Specman-Simulator Interaction
over time
‘ ’
Times are not symmetrical

Specman usually consumes a much larger
portion of the time

Getting Help
The eLRM can be found online:
http://www.ieee1647.org/downloads/ieee_P164
7_d4.pdf
In Specman’s command line, type “help
<key-word1 key-word2…>”

Basic e

e File Format
A code segment is enclosed with a begin-
code marker <' and an end-code marker '>
Both the begin-code and the end-code
markers must be placed at the beginning of
a line (left most), with no other text on that
same line (no code and no comments)
A single file can include several code
segments

Unsized numbers
Integers only:
Decimal: 7, 1009, -5
Binary: 0b101, 0b1010_0001
Hexadecimal: 0x105, 0xaabbc, 0xff_ee_00
Octal: 0o66_123
Predefined:
Kilo (1024): 128k, 512K
Mega (Kilo ^ 2): 4M, 16m

Sized numbers
As part of the number’s definition, the size of the
container is also defined (in bits):
Binary: 8’b1111_0000
Octal: 9’o4_5_6
Decimal: 8’d91
Hexadecimal: 32’xabcd_1234
If the defined size is smaller than required, MSBs
are ignored
If the defined size is bigger than required, it is
padded by zeros

Predefined Constants
TRUE, FALSE
NULL
UNDEF
Evaluates to -1
MAX_INT 231 – 1
MIN_INT -231
MAX_UINT 232 - 1
Data Types
int, uint
32 bits by default
Other sizes can by declared
!
"
# $%&
Range can be determined
' () **$) ) +, - '-
byte, bit . #
bool
time
string

Defining constants and
enumerated types
! "#
$ %& ' ' ()((((

$ %& ' ()%%%%
$ %& * + "
$, , -& ! * +#
) &$ + / '
.,/ 0 # ' - '
0 1,! , # .

Variables
Variables in e resemble variables in C++
Can be declared anywhere inside a method /
TCM
0 ,
0 1 2 ,
0 # 2 3,
/ 4 . 4
45

Working with variables
Some differences:
Casting
2 * / 67 8
$* 6 8/9 : 7 ;< ' *. . ,
= 5
Bit slicing
(1 $+ 2 (& +
(% %+ 2 $> $
Concatenation
$ 2 ?@ %4 "A - 3 C D
?@ %4 "A 2 $
" 2 ?@ %($1 $) + 4 %> ) ) 4 $($ $+4 %($& $B +A

Lists
e has a single predefined container called
‘list’
Which is in fact a doubly linked-list, a stack,
and an array
When specified, it can also be a map (keyed-
list)
Multidimensional lists are not supported

Working with lists
.,/ 2 % /! 3 ! 3 ! 0%
.,/ 2 ! 40&$ 3 ! 3 ! 0% & 56 7 6 8 6 9 6 : : 7 ;
.,/ ,&0 < / 3 ! 3 ! 0% & 56 = 7(;
.,/ / 2 0. &$ ) & 7
2 % /! 3 ! 143 ,/ #
2 ! 40&$ 3 ! 1,$$ (# >> 2 ! 40&$ 3 ! ! &0? 56 7 6 8 6 9 6 : : 7 (;
2 ! 40&$ 3 ! 1,$$ ,&0 < / 3 ! #
>> 2 ! 40&$ 3 ! ! &0? 56 7 6 8 6 9 6 : : 7 ( 6 = 7(;
2 ! 40&$ 3 ! 1$ 3 / 2 0. &$ )#
>> 2 ! 40&$ 3 ! ! &0? 56 7 6 8 6 : : 7 ( 6 = 7(;
.,/ % /! ! 2 003 2 % /! 3 ! 1 ! 2 # >>% /! ! 2 ! '

.,/ &-2 / 0% @ & 2 ! 40&$ 3 ! 140-& A 77#
>>&-2 0% @ ! &0? :
.,/ @ 3 ! 3 ! 0% & 2 ! 40&$ 3 ! 1,33 A 77#
>> @ 3 ! ! &0? 5 6 : : 7 (;
.,/ % /! @ & 2 ! 40&$ 3 ! 1% /! A 77#
>>% /! @ ! &0? 6 : :
.,/ 3,! @ & 2 ! 40&$ 3 ! 13,! A 77# >> 3,! @ ! &0? (

Import
‘import’ is used for importing data from other files
Like in Java, ‘include’ in C
‘import’ statements must be the first statements in
the file
When no extension is provided ‘.e’ is assumed
If the file is already loaded, the statement is
ignored
Import order has (sometimes catastrophic)
implications

Structs
Structs are used to define data elements and
behavior of components of a test environment.
A struct can hold all types of data and methods
All user-defined structs inherit from the predefined base
struct type, any_struct
For reusability of e code, use E ' to add struct
members or change the behavior of a previously
defined struct

(Some of) any_struct’s
predefined methods
init() – called after a struct is allocated
copy() – create a copy of the struct
pre_generate(), post_generate() – we’ll discuss
these when we get to generation
check() – we’ll discuss it when we get to checking
print() – display struct content
quit() – terminate all currently running threads
(related to this instance)
run()
Structs – example 1
BC
! /-4 <, 5
/ , # -& ! 2
/ /& # ! 2
'
;
- *
! /-4 D-,/ 3E <, 5
F '
!$ &@ < -&
;
! /-4 / ,&@3 3E <, 5

,! &@ < -&
< @< -&
; . <
FA

Structs – example 1 (cont.)
BC
2 0/ !<, ! <
) &$ D-,/ 5
/ , # -& ! 0&3 /0 ' “ ”
5
/ -/& ! $ &@ < G ! $ &@ <#
;
/ / & # ! 0&3
5
0- H D-,/ ? < , ! $ 3 &@ < 0% H ! $ &@ <#
;
;

) &$ / ,&@3 5
/ , # - & ! 0&3
5
I I &0 <, < ! 2 , &,44-/,
/ !-3 ,! &@ < G < @< # > 7
;
/ / & # ! 0&3
5
0- H / ,&@3 ? < , ,! 0% H ,! &@ < H ,&$ , < @< 0% H
< @< #
;
CA

Structs – example 2
BC
+ J ' ' K
! /-4 <, 5
E &$ + 8 3 < 4 ’ '
/ , # -& ! 2
/ /& # ! 2 ' .
?< & J ' <, 5
!$ &@ < - &
;
?< & ' K CE &$ <, 5

,! &@ < - &
< @< -&
;
; .
CA

BC
2 0/ !<, ! <
) &$ <,
5
?< & J ' CE &$ <,
5
/ , # -& ! 0&3
5
/ !-3 !$ &@ < G ! $ &@ <
;
/ / & # ! 0&3
5
0- H D-,/ ? < , ! $ 3 &@ < 0% H ! $ &@ <#
;
;

?< & ' K CE &$ <,

5
/ , # -& ! 0&3
5
I I &0 <, < ! 2 , &,44-/,
/ !-3 ,! &@ < G < @< # > 7
;
/ / & # ! 0&3
5
0- H / ,&@3 ? < , ,! 0% H ,! &@ < H ,&$ , < @< 0% H
< @< #
;
;
;
CA

Testing the “shapes” example
This works for both examples:
BC
2 0/ !<, !
) &$ ! !
5
!<, 3! 3 ! 0% <,
/-& # ! ,3!0 5
/ & !<, 3!
;
;
CA

What’s the difference?
Using ‘like’:
Using ‘when’:

So, When ‘when’?
By default
Only ‘when’ can handle orthogonal subtypes
J ' ' K L
Only when you know exactly what you want, and
inheritance is justifiable, use ‘like’
Mainly applies to test bench ‘units’
Performance-wise, ‘like’ inheritance is better
You cannot add when subtypes to a struct with
like children
And vice versa

Units
Similar to structs
Same syntax
All predefined methods that ‘any_struct’ has
(and a few more)
Units have a unique path in the runtime data
structure of an e program
Originating at ‘sys’, which is a predefined unit
Units are not meant to be data carriers

Units (cont.)
Only generated at the ‘test’ phase – before
the simulation begins
You can’t ‘new’ or ‘gen’ a unit
A unit can never be on the left hand side of an
assignment
Test bench components are implemented as
units

hdl_path()
A unit instance is bound to particular component
in the DUV
hdl_path() is a predefined method of any_unit
(returns a string) used to define the relative path of
the unit instance
- ,
< *' 22 G * H,
The HDL path can be overridden:
., ' ' #
< - 22 GI *- H,

Accessing the DUV
Both to read and write values
Awareness to the ‘z’ and ‘x’ values
Operators ‘===‘ and ‘!==‘
Ability to identify a change in the value of a
signal in the DUV
More about that when we discuss temporal
expressions
e ports – not in course material
Accessing the DUV - examples
‘3 ; 2 $; $, 8 3 < 4 3 -
‘' ’ 2 &’ ) ) $$) ) $$, . ’ . J
0 3 ' & 2 &’ $$$$) ) ) ) ,
‘' ’2 3 ' ,
0 ' % %,
' % 2 ‘' ’($ ) +,
0 .2“ ”,
‘ ’ 2 $’ $,
0 3 . 2 “3 ”,
- - ) %' @ - .
‘3 ’ 2 $’ ) , 0 43 $ '
A, 3$ 4 '3 %
' 3% J

Methods
Three types of methods:
Regular methods – execute in zero simulation time
TCMs (Time Consuming Methods) – can execute over
multiple cycles
C routines – not in this course
Once imported, a method can be overwritten,
modified, etc…
Thus violating encapsulation

Declaration - examples
3 0 & #,
/ ' - ', - 3 #
' -
7 3 0 @
K3 >2 3 0 ,
A, M9’ ‘ ’
7 ' @ '
K > 222 $; $ , -
A,
L * < 0 #,

Implementing methods
! /-4 <, 5
/ , # -& ! 2
?< & ' K CE &$ <, 5
,! &@ < - & = ' $
< @< -&
;
;
) &$ ' K CE &$ <, 5

/ , # - & ! 0&3
5
I I &0 <, < ! 2 , &,44-/,
/ !-3 ,! &@ < G < @< # > 7
;
;

Extending methods
) &$ ' K CE &$ <, 5
/ , # - & ! ,3!0
5
% ,! &@ < G < @< # M 7 N (#
5
/ !-3 / !-3 O 6
;
;
;

The importance of import order
-7 ,! 1
! /-4 7 5
= ' %
! / 0-!* , ! # ! 2
;
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
-7 6 1
! / 0-!* , ! # ! 0&3 5
0- P % 0- ? ,& 0 E !! < !E / 3 ,/&
<0? 0 E& 3Q#
;

The importance of import order
(cont.)
-7 71
! / 0-!* , ! # ! % /! 5
0- P 0 0-4< ! 0 < ,3 0 <-/ ! 0 ! ,3Q#
;
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
-7 : 1
! / 0-!* , ! # ! ,3!0 5
0- P & 0-/ E& ! 0 NQ#
;

e’s Mysterious Ways…
) &$ ! ! 5
/-& # ! ,3!0 5
.,/ 2 ! 7 & ?
2 ! 1 / 0-!* , ! #
;
;
I I I I I I I II I I I I II I I I I I I II I I I I II I I I I I I II I I I I II I I I I I
2 0/ -7 6
2 0/ -7 7
2 0/ -7 :
2 0/ -7 7
2 0/ -7 6
2 0/ -7 :
2 0/ -7 7
2 0/ -7 :
2 0/ -7 6

Returning a value from a method
Whenever a method return a value, a
variable named ‘result’ of the returned type
is allocated
In case a method which returns a value is
called and the returned value is ignored,
‘compute’ must be used
/ ,

Passing parameters to methods
A method can be declared with up to 14
parameters
But lists can be used…
Numeric, Boolean and enumerated types are
passed by value
To pass by reference, use ‘*’
3 N 4 N #@
0 2 ,
2 ,
2 ,
A,
Structs and lists are passed by reference

Time Consuming Methods
All actions supported by regular methods
can also be performed by TCMs
TCMs include time-related actions
wait, delay, sync, lock, release
Non of which can be used in regular methods
Each TCM has a sampling event
: ' # - . 0
: 7 -- -

Invoking TCMs
A regular methods cannot ‘call’ a TCM, It
must ‘start’ it
The ‘start’ action spawns a new thread which
will start running at the next occurrence of the
sampling event
Test benches are multi-threaded environments,
which makes debugging them a lot of fun…
TCMs can both ‘start’ and ‘call’ other
TCMs
Starting and calling
/ /

A simple counter in e
O @
0 . 0 ,
0 0 ,
D . 0 , O= $
D 0 ,
. 70 L # * # #,
'0 . L . 0 #,
'0 L 0 #,
' #O L . 0 #,
O 0 N #,
A,

A simple counter in e (cont.)
) &$ 0-& / 5
/-& # ! 0&3 5
! &@3 .,3- (
&! .,3- (
! ,/ @ & /, . & !#
! ,/ ,$.,&4 &@3 ! #
! ,/ ,$.,&4 &! #
! ,/ $ ! 3, 0-& / #
;
@ & /, . & ! #R! !1,& ! 0&3 5
.,/ 40-& -& 6
?< 3 ' #5
% 40-& M 6 (# (# 5
2 &! . &
; Infinite loops
40-& 40-& O 6 with no delay will
2 ! &@3 . &
?, G 4 43 cause Specman to
; get stuck
;

,$.,&4 &@3 ! #R! &@3 . & ! 0&3 5
?< 3 ' #5
&4/ 2 & 0-& / ! &@3 .,3- #
? , 4 43
;
;
,$.,&4 &! #R &! . & ! 0&3 5

?< 3 ' # 5
&4/ 2 & 0-& / &! .,3- #
? , 4 43
;
;
$ ! 3, 0-&
/ #R! &@3 . & ! 0&3 5
?< 3' # 5
0- H H ! !1 2 H < 40-& / ! H $ 4 &! .,3- #
$ 4 ! &@3 .,3- ##
? , 4 43
;
;

&4/ 2 & 0-& / .,3- G- & # ! 0&3 5
% .,3- O 6 # A 9 # 5
.,3- (
; 3! 5
.,3- .,3- O 6
;
;
; I I &$ 0% 0-& /
I I I I I I I II I & < ! 1 % 3 I I I I I I I I I II I I
) &$ ! !
5
4 0-& / ! &! ,&4
;

A simple counter in e - results

TCM Example - BFM
' ' - / / 8 L < 0
#@
- ' * C 22 ) @
/0 ' .
,
A,
' * < ,
K / / / 8 > 2 $> $,
- ' ' ' @
K / / > 2 ', O= %
3 # ,
A,
K / / / 8 > 2 $> ) ,
' * ,
A,

Concurrent execution
In many cases, we would like to perform several
actions concurrently, while synchronizing these
actions
Two main schemes
all of – perform all action blocks concurrently, continue
once all have completed
first of – perform all action blocks concurrently,
continue when one is done
Other schemes (two of) can be created based on
the above and events
Concurrent execution – all of
example
! &$* < //0/ $, , 3 ! 0% - & ! * +# $ ! 2 - & #R43E / ! . & ! 0&3 5
% $, ,1! S # (#5
/ -/&
;
$, , -! ,44 !!1304E #
,33 0% 5
5
%0/ ,4< $# & $, ,# $0 5
C #C $
? , 4 43
;
/ -’ '
; -’ '
5
C T #C 6 C 6
' .
?, $ ! 2 G 4 43
C T #C 6 C (
;
; I I &$ 0% ,33 0%
$, , -! ,44 !!1/ 3 ,! #
;

Concurrent execution – one of
example
2 0& 0/ , , & - #R43E / ! . & ! 0&3 5
% /! 0% 5
5
? , R/ ! . &
;
5
4033 4 $ $, ,143 ,/ #
? , R$ & .,3 $ / !
U
U
-’ ' -’
;
; I I &$ 0% % /! 0%
;

Comparing and copying structs
e Provides built in constructs to compare and copy structs
Like overloading ‘equals’ or ‘operator==’
The different types:
copy() – performs a shallow copy
deep_copy()
deep_compare()
deep_compare_physical()
While copy() is a predefined method of any_struct, the
others are predefined global methods

Comparing and copying structs
(cont.)
Each data member has four different attributes to control
the manner in which it is copied / compared
deep_copy
deep_compare
deep_compare_physical
deep_all
Each attribute can be assigned with one of the following
values:
Normal (default)
Reference
Ignore

Comparing and copying example
! /-4 L 5
M) - & ! 8#
;
O #O
! /-4 V 5
,6 L
,7 L
,: L
, / - ,6 $ 40 @&0/
, / - ,7 $ 40 / % / &4
, / - ,: $ 402 , ,/ / % / &4
;

Comparing and copying example
(cont.)
) &$ ! ! 5
V
/-& # ! ,3!0 5
.,/ & V $ 40 #
/& $ 402 ,/ & L K #
;
;

Packing and Unpacking
We want to convert complex data structures to a
format which will allow us to send the data to the
DUV
And the other way around
. # .
/ /
<
<

Packing – example 1
! /-4 ,4E /-4 5
M,
M
M3 & < .$
M4 3 & 3 ! 0% - & ! #
;
) &$ ! !
5
! ,4E /-4
/-& # ! ,3!0 5
.,/ !6 3 ! 0% ,4E ,4E &@130? !#
.,/ !7 - & ! 7 # ,4E ,4E &@1< @< !#
.,/ & ,4E /-4
-& ,4E ,4E &@130? !6 &#
.,/ !: - & ! : (# ,4E ,4E &@130? !#
.,/ !8 - & ! 6 (# ,4E ,4E &@130? !#
;
;
Packing example 1 - results
! /-4 ,4E /-4 5
M, (6 (6 6 (((
M (
M3 & ((((((6 (
M4 3 & 3 ! 0% - & ! # ((6 ((
(6 6 (6
;
!6 (6 6 (6 ((6 (( ((((((6 ( ( (6 (6 6 (((
!6 7= !6 (
!7 (6 (6 6 ((( ( ((((((6 ( ((6 (( (6 6(6
!: ((( (6 (6 6((( ( ((((((6 ( ((6 (( (6 6 (6
!8 ((6 (( (6 6 (6

Things get complicated…
Typically, some of the struct members are
not physical fields
Packing remains simple: only physical
fields are packed
It’s the unpacking that causes problems

! /-4 ,4E /-4 5
M,
M
3& -&
M4 3 & 3 ! 0% - & ! # < .%
;
) &$ ! !
5
! ,4E /-4
/-& # ! ,3!0 5
.,/ !6 3 ! 0% ,4E ,4E &@130? !#
.,/ !7 ,4E /-4
-& ,4E ,4E &@130? !6 !7#
;
;

! /-4 ,4E /-4 5
M, (6 (6 6 (((
M (
3& -& 7
M4 3 & 3 ! 0% - & ! # ((6 ((
(6 6 (6
;
!6 (6 6 (6 ((6 (( ( (6 (6 6 (((
!7
, (6 (6 6 (((
(
3& -& (
D 43& 3 ! 0% - & ! # 2 3! #

! /-4 ,4E /-4 5
M,
M
3& -&
M4 3 ! 0% - & ! # < ."
E 3& 41! S #
;
) &$ ! !
5
! ,4E /-4
/-& # ! ,3!0 5
.,/ !6 3 ! 0% ,4E ,4E &@130? !#
.,/ !7 ,4E /-4
-& ,4E ,4E &@130? !6 !7#
;
;

! /-4 ,4E /-4 5
M, (6 (6 6 (((
M (
3& -& 7
M4 3 ! 0% - & ! # ((6 ((
(6 6 (6
;
!6 (6 6 (6 ((6 (( ( (6 (6 6 (((
!7
, (6 (6 6 (((
(
8 . # 3& -& (
4 3 ! 0% - & ! # ((6 ((
(6 6 (6

Unpacking problems
In case there are not enough bits in the unpacked list to fill
all physical field, an error is issued
Non-physical fields are assigned with their default value
When enumerated types are concerned, this may yield a ‘bad enum
value’ (see examples Packing4 & Packing5)
When the first list of unlimited size is encountered, all
remaining data will be inserted to this list
To solve these, manual interference is required
Setting some values before unpacking
Verifying integrity after unpacking
Extend ‘do_unpack’

Packing &Unpacking – summary
Always use the same “direction” as used when packing
(low low, high high)
When a struct contains other structs, packing is done
recursively
Only on physical fields!
Specific packing and unpacking can be tailored by using
the ‘packing_options’ struct
Or by extending ‘do_pack’ and ‘do_unpack’
See the eLRM for more
No sense in packing units (so no physical fields either)…

Test Generation
Generation is the process of creating stimuli
Specman has a built in generator
When not specified by the ‘do-not-generate’
construct, each field is assigned with a random
value upon instantiation
Constraints are used to express relations
between fields

Generating stimuli
PK
' - / 67 8 &, : $
' - / / 8 &,
< @
? /'' / 67 8 ,
? . /'' / 67 8 ,
? # ' C $B ,
? # ' - / / 8 ,
? # / / 8 ,
A,
KQ

Constraining the stimuli
The source address is different than the target
address
< /'' D2 . /'' ,
The value of the ‘payloadSize’ field equal the
payload’s size
< # ' C 22 # '* C ,
The payload size is larger than 4, but smaller than
1024
< # ' C ( **$) % +,

Soft constraints
Soft constraints are used to direct
Specman’s generator towards desired values
A specific desired value
A weighted uniform distribution over ranges
In case a soft constraint conflicts with hard
constraints, it is ignored
In case a soft constraint conflicts with a
subsequent soft constraint, it is ignored

Hard and soft constraints
When hard constraints (explicit or implicit)
conflict, generation fails
When a soft constraint conflict hard constraints, it
is ignored
Use hard constraints (keep) to express constraints
defined in the design spec
Use soft constraints (keep soft) for default values
and to direct the generator towards “interesting”
cases

Constraining the parity value
By default, we would like the parity field to
contain the parity value of payload
But later we’ll want to test the DUV with
packets with bad parity
# # ,
< # # 22 6 7 22 # 22
# # ' ,
< - # # 22 6 7 ,

Constraining the parity value –
alternative solution
In case Packet_S has already been defined, and we
have no access to the source, the previous solution
might be impossible
This is due to generation order (to be discussed soon)
# # ,
. @
- # # 22 6 7 @
#2 # # ' ,
A @
. #< .@
D2 # # ' ,
A,
A,
A,

Constraining the payload size
We would like to generate packets with the following
distribution over payload size:
20% - 4 bytes
20% - [5..10] bytes
20% - 1024 bytes
40% - others
< - # ' C 22 @
$ ,
$ (1 **$) +,
$ $) % ,
% ,
A,

Constraining the payload itself
To make debugging easier, we want each
item in the payload to hold it’s location in
the list
E ' < @
' # ( 7 : 4 6 /9 M = +,
< - ' # 22 7 : ,
3 7 : >' # @
< - # ' @
22 ' E ? 3 %4 / / 8 ,
A,
A, /0 ' .‘ ’– ’
A, ' '3 ’ 3 <
'
Constraining the payload –
alternative solution
E ' < @
' # ( 7: 4 6 /9 M = +,
< - ' # 22 7 : ,
3 7 : >' # @
< - # ' @
' E 22 ) 2Q 22 ) ,
' E D2 ) 2Q 22 0R$ ? 3 %4
/ / 8 ,
A,
A,
A,

Generation order
Specman tries to generate values for the
fields based on the order in which they
appear
In case the value depends on the returned value
from a method, all method parameters must be
generated first
Generation order may cause soft constraints to
be ignored

The default generation order
/
/* .
/*.
* .
*.
* .
/* .

Generation order – example 1
< @
? # ' - / / 8 ,
# # ,
? # / / 8 ,
< - # # 22 6 7 ,
< # # 22 6 7 22 # 22 # # ' ,
A,
What would happen if ‘ # # ’ and ‘ #’ were
declared in reverse order?
The probability of getting good parity would be nearly 0!

< @
, : 1
,
,
< 22 22 ,
A,
What would be the distribution among
equalities?
No declaration order will fix this! If ‘a’ is
declared last, the generator will fail

< $ @
< ' ( = / 4 = 7 8 = 4 8: +, : %
C () **$) ) ) +,
< # 22 = / 22 C P 1 ) ) ,
< # 22 = 7 8 = 22 C 22 1 ) ) ,
< # 22 8: 22 C Q 1 ) ) ,
A,
What would happen if ‘kind’ and ‘size’ were declared in reverse
order? 600
500
400
300
200
100
0
SMA LL M EDIUM BIG

Specifying explicit order
A different solution to the previous
problem:
< . # - C ,
Note that this is not always possible. What
happened if we tried adding the following
constraints to Packet_S:
< . # - # ' ,
< # # 22 6 7 ,
Driving the generator crazy…
! /-4 ,4E 6 5
, -&
0! @ & /, # ! ,3!0 5 : "
, , O 6(
;
;
! /-4 ,4E 7 5
) -&
,4E 6
S -&
? -&
&-2 -& # -& ! 5 / !-3 &-2 ;

E ) 1,
E S 1,#
E ? 1,
;

Constraint evaluation order
No meaning to hard constraints order
Soft constraints are evaluated in reverse
order of appearance
Follows a methodological concept that the later
a constraint appears, the more relevant it is
Constraints that appear in the test itself (which is the
last to be imported) are the most relevant ones

Constraint evaluation order -
example
struct Packet_S {
360
350
340
size : uint [1..3]; 330
320
}; 310
300
1 2 3
------------------------------
keep soft size == 1; 1200
1000
keep soft size == 3;

800
600
400
200
0
: 1 2 3

Constraint evaluation order –
example (cont.)
keep soft size == 3; 1200
1000
keep soft size == 1;

800
600
400
200
------------------------------ 1 2 3
1200
1000
keep ((soft size == 1) or 800
600
(soft size == 3)); 400
200
0
1 2 3

Constraint evaluation order –
example (cont.)
keep soft size in [1,3]; 600
500
400
300
------------------------------
200
100
0
1 2 3
keep soft size != 2; 600
500
400
300
200
100
0
1 2 3

Constraints are not assertions!
Once generation is complete, they are not enforced
Even during post_generate()
() **$) +,
,
,
< 22 ,
' - , : B
,
< 22 '* C ,
. @ 2 %) ) , A,
@
2 R $,
'* ,
2 R $,
A,

Abusing constraints
e constraints are also used for:
Setting default values
W ! / &@ E !0% W H43EH
' ! / &@ E !0% ' H/! H
- 3
Setting unit references

2 0& 0/ X /,@ 0& 0/ ! &! ,&4
%2 X /,@ X ! &! ,&4
4< 4E / X /,@ < 4E / ! &! ,&4
E %2 12 0& 0/ 2 12 0& 0/
E 4< 4E /12 0& 0/ 2 12 0& 0/

On-the-fly Generation
All generation examples we’ve seen for far
were performed in the ‘test’ phase (before
simulation really begins)
In many cases, we’d like to create stimuli
during simulation
Decide the next step in the test based on the
state of the DUV

On-the-fly Generation - example
) &$ ! ! 5
/-& # ! ,3!0 5
.,/ ,$$/ !! - & ! ' * +# (
.,/ ! S -& ! 6=# (
.,/ ,4E ,4E
%0/ %/02 ( 0 $0 5
@ & ,4E E &@ 5
1 ,/@ $$/ !! ,$$/ !!
!0% 1 , 30,$ S !S
;
,$$/ !! ,4E 1!0-/4 $$/ !!
!S ,4E 1 , 30,$ S
; : !
;
;

Generation - summary
Generating quality stimuli has a huge
impact on the verification effort
Using e makes it easy to express constraints
and preferences, but it’s much harder to get
what you REALLY wanted
Test your generator
Perform input coverage at an early stage

Events and Temporal
Expressions (TE)
The e language provides temporal constructs for
specifying and verifying behavior over time
Events are used for:
Synchronizing the test bench with the DUV
Synchronization within the test bench
Events are struct (or unit) data members
All user defined events are automatically included
in functional coverage

Evaluating Events and Temporal
Expressions
Events - start evaluating when run() is called
And terminate when the struct is destroyed
TEs in a 3 action start evaluating as soon as
that action is reached
And terminate when the 3 continues
Sub expressions start evaluating when they are
reached in the expression
The TE is visited every time the sampling event
occurs
Performance, performance, performance

Event State
An event can be in one of three states:
Succeed – when the TE described is fulfilled,
the event is emitted
Failed – the beginning of the TE has occurred,
but not the entire TE
Pending

Predefined events
‘sys.any’
Emitted at any Specman time tick
‘sim’
Emitted whenever there’s a changes in any of the
DUV’s signals’ values
The primary mean of synchronization between test
bench and DUV
The ‘root’ of all DUV related events
When working in standalone mode (no simulator),
the ‘sim’ event cannot be used
‘wait delay’ can’t be used either

Synchronizing the test bench with
the DUV
The most basic events: identifying
changes in signals
O M OF ., < - O M OF 22 G <H,
0 < 0 K O M OF > L ,
0 < - 0 - K O M OF > L ,
0 < . 0 . K O M OF > L ,

Synchronizing the test bench with
the DUV (cont.)
Since ‘sim’ is the sampling event, any
change in ‘clk’ value will result in the
appropriate event
“Immediately” – at the same simulation time
Only ‘rise’, ‘fall’, and ‘change’ can be
attached to the ‘sim’ sampling event
‘rise’ and ‘fall’ of multiple-bit signals is
interpreted based on value
Any bit change triggers ‘change’

Determining the sampling event
Analyzing the appropriate sampling event
has an impact on correctness and
performance
The event is checked every time the sampling
event occurs = C
‘ ’ '
67 7 ., < - 67 7 22 G H, ‘ # * #’
#
0 # 0 K 67 7 >L ,
#
0 # 0 K 67 7 >L < 0 ,

Events - Example
W ! / &@ E !0% W H143EH
! / &@ E !0% H1,H 70
! / &@ E !0% H1 H
. & 43E / ! . & ! / ! C W #C#R! 2

. & , /! . & ! /! C #C#R! 2
. & 4<,&@ . & ! 4<,&@ C #C#R43E / ! . &
. & , < @< 0& 43E / ! ! /- C #F 6 #R43E / ! . &
. & 0& ,% / , ! 5R, / ! . & 6 ;R43E / ! . &
. & , 0/ 0& ,% / , ! R, / ! . & 0/
R0& ,% / ,#R43E / ! . &
. & , 0/ ! R, / ! . & 0/
R 4<,&@ . & #R43E / ! . &
. & , ,&$ ! R, / ! . & ,&$
R 4<,&@ . & #R43E / ! . &

Events - Example Results

Emitting events from e code
Not all events must be related to DUV signals
Emitting events can be used to:
Synchronize TCMs
Communicate between TB Components
Event-based relationships between components are harder to
create and debug, but make decoupling easier
Trigger coverage (more in the relevant slides)
A DUV-related event can also be emitted
# -
' * ' ' .

Event-based relationships
The alternative:
Unit A points to unit B
To communicate with unit B, A calls B’s methods
If B is NULL, an error occurs
Event-based:
Unit B points to unit A
A emits a local event
B responds to the event defined in A
Order is hard to predict, two simultaneous emissions result in
one response

Synchronizing e code with the
DUV
TCMs can be synchronized with the DUV based
on events
When not specified, all synchronization actions
are related to the TCM’s sampling event
Three main actions:
wait
sync
Can be used to synchronize the TCM with its sampling event
wait delay

Wait, Sync and Wait delay
0 0 ; 8: / ; L , # #
0 < 0 ;O F ;L ,
3 L < 0 @
3 L 0 ,
3 ' 0 ,
A,
# L < 0 @
# L 0 ,
# ' 0 ,
A,
' # L < 0 @
3 ' # $1) ,
' # ' 0 , M # C '
A,
S -

Wait, Sync and Wait delay
(cont.)
Whenever a sampling event is not defined,
the TCM’s sampling event is used
Complex TEs can be attached to ‘wait’
Most common:
3 (" + N # ,
0 ' 2. # ,
3 ('+ N # ,

Temporal Expressions
The combination of events, along with some
operators, used to describe behavior over
time
The e language provides a set of temporal
operators that can be used to construct TEs
Relationships between events
Value of fields
…

TE – Example 1
0 $ @L , L AL < 0 ,
0 % @L , L , L AL < 0 , 7$
0 " @L $, L AL < 0 ,
0 @L , (%+ N L AL < 0 ,

TE – Example 2
0 $ @L , (" + , L AL < 0 ,
0 % @L , (%**1 + , L AL < 0 ,
7%
0 " @L , I(%**1 +, L AL < 0 ,
0 @L , I(**+ , L AL < 0 ,

TE – Example 3
0 $ @L , L AL < 0 ,
0 % @L , L A L < 0 , 7"
0 " - @L , L A L < 0 ,
0 L $L < 0 ,
0 1 - L $L < 0 ,

TE – Example 4
0 $ @L , L , L AL < 0 ,
0 % @L , L , L A L < 0 ,
0 " - @L , L , L A L < 0 ,
0 L $L < 0 ,
0 1 - L $L < 0 ,

TEs – Order of Evaluation
Specman provides no ways of predicting the
order of event evaluation
But is consistent: once the order is decided, it
remains (whether you like it or not)
There are additional predefined events that
can be used to force order
sys.tick_start, sys.tick_end
’ # ' ' .

TEs –Race Conditions
Since order is not guaranteed, race conditions can
occur:
not @a, @a and fail @a can all succeed at the same
time! /. ' ' TM
'' .3 .
Requires human “intervention”:

Specman evaluate the TEs and determines ‘not @a’ has
occurred
‘a’ is emitted (from the e code)
@ ,A 7

Comments on TEs
TEs can be used as part of the definition of
other TEs
Might have different semantics than using the
expression itself
There are additional operators:
detach, consume, yield (=>)
We’ll discuss ‘=>’ as part of checking
Consult the eLRM
Comments on TEs (cont.)
Every time the triggering event occurs,
Specman starts evaluating an instance of the
TE
A single event instance can trigger several
events (one of each type)
There could be several pending events of the
same type simultaneously
A single event can complete the evaluation
of several events (can be of same type)
Attaching Action Code to Events
Using ‘ ’, action code can be attached to
events, so the code is executed every time
the event occurs
The event must be local
The action code cannot contain any time
consuming actions
But you can ‘ ’ a TCM
Should include a single call to a method
0 @ #= . , A,

Replicating Events from other
Structs / Units - Example
-& K6 5
! / &@ E !0% H1,H
. & , ! /! C #C#R! 2
-& K7 5 M
0&6 - K6 ! &! ,&4
. & , ! R0&6 -1,

0& , 5 ! 3, !!,@ # ;
;

Events and Temporal
Expressions - summary
Events and TEs are a basic building block
in the e language
To synchronize the TB with the DUV
A must for temporal protocols
To identify interesting occurrences in the DUV
For checking and coverage
Debug your events
To make sure they mean what you intended

Checking
There’s no real point in driving stimuli
without verifying that the DUV behaves in
accordance with its specifications
Two types of checks:
Data checks
During simulation
After simulation
Temporal checks
Data checks
Refers to verifying the output content
data_out = F(data_in)
During simulation
Helps pinpoint the exact time in simulation when the
bug had affect
Less data accumulated in the test bench
No waste of simulation time
After simulation
Sometimes it’s the only option…
dut_error
<U . < 4 E < #@
0 - .2' # 4 E 4 = /V 89 ,
- * C Q)
@ ‘ < ’ ‘ -’
' WO - ' E '- . - ' W4 ,
A,
A,
dut_error_struct is a predefined struct which

defines Specman’s response to errors
By manipulating it you can fine-tune the error handling
mechanism
See the eLRM for more

Checker - Example
- . '@
< E ' - . * C D2 )
' W . ' E '- . W,
- E ' - . * C D2 )
@ <U . *. U . 4
E ' - . * ) , A,
A, = < # <
-
<U . < 4 E < #@
0 - .2' # 4 E 4 = /V 89 ,
< * C Q)
' WO - ' E '- . - ' W4
,
A,

Post-Simulation Checks
Every struct / unit has a predefined method
< that is called at the end of simulation
After is called
In other special cases – see the eLRM for more
< @
< E ' - . * C 22 )
' W 4 W4
E ' - . * C 4W ' .- . W,
A,
7 . -
- ' .#
Temporal Checks
Declaration of behavioral rules, and
verifying actual behavior complies with
them
Typical rule structure:
TE a must be followed by TE b
If-then pattern
TE x never occurs

Temporal Checks - Example
The request signal is never asserted for
more than one cycle
0 X . 0 ; 6 7 Y ; 222 $ L < 0 ,
0 3 X @(%+ N L X . 0 AL < 0 ,
3 X @' 6 7 Y 4W . '-
# W , A,

Temporal Checks – Example
(cont.)
Alternative phrasing: In case the request
signal rises in this cycle, it should fall at the
next
0 X ; 67Y ; L < 0 ,
0 X - - ; 67Y ; L < 0 ,
E 3 X L X 2Q
L X - L < 0 ' W . W 46 7 Y 4
W '- # W,
Are both checker equivalent? .

. 3 “

Temporal Checks - Example
Every request (an assertion of the request
signal) is eventually acknowledged
E X < ' L X 0 2Q @(**+ ,
L < 0 AL < 0 ' W/
< 3 '. ' X ' 'W ,
Not good enough! O <

Temporal Checks – Example
(cont.)
A different solution
E X < ' L X 0 2Q @(**+ N
LX ,L < 0 AL < 0
' W/ < '. ' X ' 'W ,
An equivalent checker:
E X < ' L X 0 2Q @ 0 #
L < 0 AL < 0 ' W/
< '. ' X ' 'W ,
Still not good enough…

Checking - summary
Good checking is crucial to the DUV’s tape-out
readiness
Verify your checkers:
Prove they cover all possible case
False negatives
False positives
Review them – with other verification engineers as well
as the DUV’s designer
Make sure they’re activated
But leave an option of turning them off

Checking – summary (cont.)
Always use ‘check that’
Not ‘if-then’ or ‘on’
Using ‘expect’ is equivalent to using ‘check that’
Specman “understands” it’s a checker
Performance wise, it is much better to write your
assertions in RTL
Using PSL or its likings
Specman has some advantages over PSL, but they are
mostly negligible

Coverage
Different types of coverage:
Code coverage
Toggle coverage
Functional coverage
…
We’ll discuss functional coverage

Functional Coverage
A metric to measure the DUV’s readiness
for tape out:
Have we tested all features? How hard have we
tested them?
Which features haven’t been tested?
A useful tool in test bench debugging:
Is the generator creating all expected stimuli?
Do the checkers work?

Coverage using e & Specman
Two main elements are required to define a
coverage group:
An event – to define when to sample
Coverage items – to define what to sample
By default, coverage is collected per-type
There is an option to collect per-instance, but
it’s beyond the scope of the course

Coverage – Example 1
! /-4 40$ 5
E &$ 02 2 ,&$
M0 40$ 40$ O 0$
E E &$ ' +# 0 40$ & ##
?< & CE &$ 40$ 5

M/ @ ! / ' @! /
M2 2 ,$$/ $$/ !!
E 0 40$ ' # A / @! / & 6 (11: 6 ##
;
? < & ' + CE &$ 40$ 5

M0 /,&$6 ' @! /
M0 /,&$7 ' @! /
E 0 40$ # A 0 /,&$6 & (117( ##
;
. & 0 40$ 40. /,@ . &

;
Covering struct/unit members
Requirement: All opcodes are being used
E 'M ' @
0 ' 0 . 0 @
' ,
A,
A,
A more readable version:

E 'M ' @
0 ' 0 . 0
. E 2 WM ' 0 . W @
' . E 2 WM ' # W,
A,
A,

Covering cross product
Requirement: All arithmetic opcodes are
used with all possible operands
E 'M ' @
0 ' 0 . 0
. E 2 WM ' 0. W @
' . E 2 WM ' # W,
A,
3 /6 ;< ' M ' @

0 ' 0 . 0 @
'$,
' 4 '$,
A,
A,
A,

Covering cross product -
problems
The @ ' 4 '$A cross product
contains many invalid values:
The memory access opcodes, M / and
M 6 7 , are a part of the opcode set, but are
not arithmetic
In case the opcode is / , registers [21..31]
are not used

Covering cross product –
removing invalid values
3 /6 ;< ' M ' @
0 ' 0 . 0 @
'$,
' 4 '$
. E 2 WO ' - ' '
'$W4
. 2 ' ( M / 4 M 67+
' 22 / '
'$ () **%) + ,
A,
A, < .
- 0 .
Covering cross product – more
problems
'$ is being over graded
We only intended on collecting it for the purpose of the
cross product
' and @ ' V '$A are given
equal weights
The ' set contains four valid values
The @ ' 4 '$A cross product contains 53
valid values
Current version gives each of the item 50% of the
group’s weight

Using weights
E 'M ' @
0 ' 0 . 0
.3 . 2 1! 4
E 2 WM ' 0 . W @
' 3
. E 2 WM ' # W4 '. 3 .
3 . 2 , ' - ' '
A,
3 /6 ;< ' M ' @

0 ' 0 . 0 @
'$ . #,
' 4 '$
. E 2 WO ' - ' ' '$W4
3 . 2 1"4
. 2 ' ( M / 4 M 67+
' 22 / ' '$ () **%) + ,
A, A, A,

Covering multiple hits
Requirement: all options of opernad2
are being used, at least twice each
3 /6 ;< ' M ' @
0 ' 0 . 0 @
'%
. E 2 W7 0 # - ' %4
3 W4
2 %4 3 . 2 B %,
A,
A,

Covering ranges
Requirement: every address is being used
3 = 7 = ;< ' M ' @
0 ' 0 . 0 @
'' ,
A,
A,
Problems:
Specman’s coverage report will have this
item grayed out
We don’t really care about EVERY address
Covering expressions
Fixed requirement: every address within a page is
being used
3 = 7 = ;< ' M ' @
0 ' 0 . 0 @
'' 1 2 '' ?
/: 7 8Z 7 ,
A,
A,
Problems:
For large pages, the bucketing problem is still not
solved
not all addresses within a page are equally interesting

Covering ranges (cont.)
Fixed requirement: every range within a
page is being used
3 = 7 = ;< ' M ' @
0 ' 0 . 0 @
'' 1 2 '' ? /: 7 8Z 7
. . 2@
. () +4W . W4 9 7 U 4 " ,
. ($**" +4 W9 . W4 9 7 U 4 " ,
. ( **%! +4 WW4 &4 ,
. (%&**" ) +4 W9 ' - . W4 9 7 U 4 " ,
. (" $+4 W . 'W4 9 7 U 4 " ,
A4
3 . 2% ,
A,
A,

Coverage example 2 - FSM
Simple FSM example
There is an ‘fsm_enable’ signal. Whenever
‘fsm_enable’ is de-asserted, any FSM behavior
is allowed
Not a very realistic example
$ %
&

Conditional coverage and
transition coverage
Requirement: every state is visited, every
transition is traversed
0 - . 0
. E 2 WU = . 0 . W4 O 0%
3 2 - ' @
2; / 7 ;
. E 2 WU = W4
. 2 D2 ; ) ) ) $ ' D2 ; ) )$) ' D2 ; )$) )
' D2 ; $) )) ,
,
A,
Problem: not all transitions are legal

Conditional coverage and
transition coverage (cont.)
0 - . 0
. E 2 WU = . 0 . W4
3 2 - ' @
2; / 7 K
. E 2 WU = W4
3 . 2 4
. 2 D2 ; ) ) ) $ ' D2 ; ) )$)
' D2 ; )$)) ' D2 ; $) )) ,
. E 2 WU = W4
3 . 2 $) 4
. 2
0 22 ; ) )$) ' 22 ; )) $)
0 22 ; )$) ) ' 22 ; ) $) )
0 22 ; $)) ) ' 22 ; $) ) )
0 22 ; ) )$) ' 22 ; )) ) $
0 22 ; ) )$) ' 22 ; $) ) )
0 22 ; $)) ) ' 22 ; ) ) $) ,
A,
There are still some problems…
Coverage - notes
You can’t define two coverage groups
based on the same event
But you can extend a group using ‘is also’
Extensions are concatenated
See eLRM for more
Coverage groups should not be defined
under ‘when’ subtypes, only extended there

Coverage – notes (cont.)
Item ranges may intersect
In case an item hit fits several ranges, it will
be counted as a member of the first range
(by order of definition)
In case an item hit fits no range, a range
named ‘others’ is created
You can create ‘other’ yourself (and require
number of hits…)

Coverage – notes (cont.)
The same regression may yield different results in
case the weights are modified
The manner in which item and group weights are
defined is a part of the methodology. Options:
All items weigh 1, group weighs according to number
of items
Each item weighs based on the valid space size, group
weighs as sum of item weights
Based on item / group “importance” – this is a pitfall!

Functional Coverage - summary
Specman includes simple, yet powerful, constructs
to define coverage items
For complex items, “arranging” the data to be covered
is sometimes needed
Coverage groups and items should be defined
separately from other test bench components
Collecting coverage begins when the DUV has reached
some level of maturity
Has implications on simulation performance

Functional Coverage – summary
(cont.)
A significant mean to measure the DUV’s
tape out readiness
Must be tightly coupled with effective checking
Cannot replace the verification engineer’s gut
feeling…

Introduction To Specman and The: e Programming Language

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Specman and The: e Programming Language

Uploaded by

Copyright:

Available Formats

Introduction to Specman and the

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

Times are not symmetrical

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

$ %& ' ' ()((((

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

.,/ % /! ! 2 003 2 % /! 3 ! 1 ! 2 # >>% /! ! 2 ! '

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

! /-4 / ,&@3 3E <, 5

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

?< & ' K CE &$ <, 5

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

?< & ' K CE &$ <,

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

) &$ ' K CE &$ <, 5

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

Structs and lists are passed by reference

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

,$.,&4 &! #R &! . & ! 0&3 5

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification