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…

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

 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…
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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
©Amir Nahir(2007) 236605 – Simulation Based Functional 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

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

 The Simulation Environment

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

 Specman-Simulator Interaction
over time

‘ ’

Times are not symmetrical

Specman usually consumes a much larger
portion of the time

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

 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…>”

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

 Basic e

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

 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

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

 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

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

 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

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

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

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

 Defining constants and
enumerated types
! "#

$ %& ' ' ()((((

$ %& ' ()%%%%

$ %& * + "
$, , -& ! * +#

) &$ + / '
.,/ 0 # ' - '
0 1,! , # .

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

 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

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

 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

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

 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

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

 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? (

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

 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

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

 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

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

 (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()
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 Structs – example 1
BC

! /-4 <, 5
/ , # -& ! 2
/ /& # ! 2
'
;
- *
! /-4 D-,/ 3E <, 5
F '
!$ &@ < -&
;

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

,! &@ < -&
< @< -&

; . <

FA

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

 Structs – example 1 (cont.)
BC
2 0/ !<, ! <

) &$ D-,/ 5
/ , # -& ! 0&3 /0 ' “ ”
5
/ -/& ! $ &@ < G ! $ &@ <#
;

/ / & # ! 0&3
5
0- H D-,/ ? < , ! $ 3 &@ < 0% H ! $ &@ <#
;
;

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

 Structs – example 1 (cont.)
) &$ / ,&@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

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

 Structs – example 2
BC

+ J ' ' K

! /-4 <, 5
E &$ + 8 3 < 4 ’ '
/ , # -& ! 2
/ /& # ! 2 ' .
?< & J ' <, 5
!$ &@ < - &
;

?< & ' K CE &$ <, 5

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

CA

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

 Structs – example 2 (cont.)
BC
2 0/ !<, ! <

) &$ <,
5
?< & J ' CE &$ <,
5
/ , # -& ! 0&3
5
/ !-3 !$ &@ < G ! $ &@ <
;

/ / & # ! 0&3
5
0- H D-,/ ? < , ! $ 3 &@ < 0% H ! $ &@ <#
;
;

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

 Structs – example 2 (cont.)

?< & ' 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

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

 Testing the “shapes” example
This works for both examples:

BC
2 0/ !<, !

) &$ ! !
5
!<, 3! 3 ! 0% <,
/-& # ! ,3!0 5
/ & !<, 3!
;
;

CA

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

 What’s the difference?
Using ‘like’:

Using ‘when’:

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

 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

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

 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

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

 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

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

 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,

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

 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
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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

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

 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

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

 Declaration - examples
3 0 & #,

/ ' - ', - 3 #
' -
7 3 0 @
K3 >2 3 0 ,
A, M9’ ‘ ’
7 ' @ '
K > 222 $; $ , -
A,

L * < 0 #,

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

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

) &$ ' K CE &$ <, 5

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

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

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

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

 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#
;

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

 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#
;

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

 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 :
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 7
2 0/ -7 6
2 0/ -7 :
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 7
2 0/ -7 :
2 0/ -7 6
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

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

 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
/ ,

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

 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

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

 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 -- -

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

 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
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 Starting and calling
/ /

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

 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,

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

 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
;

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

 A simple counter in e (cont.)
,$.,&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
;
;

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

 A simple counter in e (cont.)
&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
;

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

 A simple counter in e - results

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

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

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

 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
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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 ,! #
;

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

 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%
;

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

 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

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

 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

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

 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
;

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

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

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

 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
. # .
/ /

<
<

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

 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? !#
;
;
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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

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

 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

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

 Packing – example 2
! /-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#
;
;

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

 Packing example 2 - results
! /-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! #

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

 Packing – example 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#
;
;

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

 Packing example 2 - results
! /-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

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

 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’

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

 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)…

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

 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

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

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

KQ

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

 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 ( **$) % +,

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

 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

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

 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

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

 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 ,

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

 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,

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

 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,

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

 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 <
'
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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,

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

 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

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

 The default generation order

/
/* .

/*.

* .

*.

* .

/* .

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

 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!

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

 Generation order – example 2
< @
, : 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

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

 Generation order – example 3
< $ @
< ' ( = / 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

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

 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 ,
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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,
;

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

 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

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

 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

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

 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

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

 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

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

 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,

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

 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/

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

 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

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

 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
; : !
;
;

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

 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

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

 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

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

 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

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

 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

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

 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

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

 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 ,

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

 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’

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

 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 ,

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

 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 / ! . &

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

 Events - Example Results

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

 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
# -
' * ' ' .

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

 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

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

 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

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

 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 -

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

 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 # ,

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

 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
…

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

 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 ,

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

 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 ,

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

 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 ,

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

 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 ,

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

 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
’ # ' ' .

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

 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

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

 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
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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)
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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,

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

 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, !!,@ # ;
;

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

 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

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

 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
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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…
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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

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

 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,

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

 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 . -
- ' .#
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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

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

 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,

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

 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 “

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

 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 <

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

 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…

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

 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

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

 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

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

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

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

 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?

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

 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

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

 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. /,@ . &

;
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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,

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

 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,

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

 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

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

 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 .
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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

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

 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,

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

 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,

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

 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
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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

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

 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,

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

 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
$ %

&

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

 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

©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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…
©Amir Nahir(2007) 236605 – Simulation Based Functional Verification
 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

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

 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…)

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

 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!

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

 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

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

 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…

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