See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/331047875
The e Hardware Verification Language
Presentation · May 2016
DOI: 10.13140/RG.2.2.36677.40166
CITATIONS READS
0 284
1 author:
Behnam Farzaneh
University of Regina
20 PUBLICATIONS 110 CITATIONS
SEE PROFILE
All content following this page was uploaded by Behnam Farzaneh on 12 February 2019.
The user has requested enhancement of the downloaded file.
In the name of God
The e Hardware Verification Language
Presented By:
Behnam Farzaneh
May 2016
1
outline
e & Key features of e
e & HDL Hierarchy
Execution Flow
e as a Verification Language
Specman
eRM
eVC
References
2
e
Developed by Yoav Hollander in 1992 in Israel
Developed by Verisity (now Cadence)
Introduced at the 1996 Design Automation Conference
Specman Elite and Enterprise Simulator (XL)
Standardised as IEEE 1647
e combines OOP and AOP
Typically used in large system designs
e is capable of interfacing with VHDL, Verilog, C, C++ and
SystemVerilog
e is a tool used in design verification
3
e (Cont’d)
The verification-specific constructs that distinguish e from
other object-oriented languages such as C++ include:
Constraints
Multi-threaded execution
Bit-level access
Clocks
Designed for the development of verification environments
e provides powerful constructs for design verification
Contains all the constructs necessary for a complete
verification tool:
Allows objects in the verification environment to be extended
Focus on verification-oriented features
4
Key features of e
Random and constrained random stimulus generation
Functional coverage metric definition and collection
Can be used for writing assertions
Aspect-oriented programming language
Can create highly reusable code
Implementing highly flexible and reusable verification
testbenches
Extendability
5
Struct
Objects are modeled using the struct construct
Similar to class in C++
Every struct object has a number of predefined methods
A base struct type can be extended by adding members
Structs are used to define data elements and behavior of
components of a test environment
Structs are the basis building blocks for e language based
testbenches
Structs are dynamic object and represent objects that are
created and destroyed during simulation time, e.g., bus
data packets that are passed between agents in a system
6
e Hierarchy
“sys” is implicitly defined
Top most struct in Verification environment
All user data should be instantiated under sys
7
e Hierarchy (Cont’d)
<'
struct data { struct error {
<data internals> <error internals>
}; };
struct protocol {
<protocol internals> struct driver {
}; <driver internals>
struct collect { };
<collect internals>
};
8
e Hierarchy (Cont’d)
struct checker {
data1: data; extend sys {
protocol1: protocol; driver1: driver;
<checker internals> checker1: checker;
}; receiver1: receiver;
};
struct receiver {
collect1: collect;
'>
error1: error;
<receiver internals>
};
9
Execution Flow
Verification tasks are generally divided into a
number of phases:
Initialization
Pre-Run Generation
Simulation Run
Post-Run Result Checking
Finalization
10
Execution Flow (Cont’d)
Merging User Code into the Implicit Execution Order
Predefined methods of a struct that relate to this
execution order are:
• setup()
• init()
• pre_generate()
• post_generate()
• run()
• check()
• finalize()
11
12
Steps to Writing an e Program
Design the program using object oriented programming
principles
Define user defined objects using structs
Create user data struct hierarchy by extending sys
Insert user’s program in the predefined execution flow by
extending predefined methods of sys and other user-
defined structs
13
e as a Verification Language
Structure of an e Program Constrained Random
Statements Generation
Methods HDL Simulator Interface
Extension Statements Units
Concurrency and Thread e-Ports
Control Packing
Events Unpacking
Temporal Expressions Functional coverage
Time Consuming Methods
14
e as a Verification Language
Verification activities include:
Simulation Abstraction
Generating Stimulus
Driving Stimulus
Collecting Device Response and Result Checking
Measuring Verification Progress and Coverage
Collection
15
16
Structure of an e Program
Lexical Conventions
User-defined names in e consists of any length
combinations of alphabet characters, underscore, and
digits (i.e. _, A-Z, a-z, 0-9)
Valid names cannot start with a number
reserved keywords in the e language cannot be used as
user defined names
e is a case sensitive language
17
Structure of an e Program (Cont’d)
Code Segments
e programs are a collection of Code Segments.
The beginning and end of a code segment are marked
with begin-code <’ and end-code ‘> markers
code blocks are enclosed with braces and end with a
semicolon:{…;…;…;};
Comments
18
Import statements
Import is used for importing data from other files
include in C
Import statements are used to tell the compiler to load
another e program file before compiling the current e
program file
Import statements must appear before all other statements
inside the first code segment in a file
19
Methods
Methods are struct members that are used to perform
operations on struct data members, or any other value that
the method can access
Methods are defined by specifying the name, the
parameter list, the return type (if any) and the actions in
the method
Predefined or user defined
20
Extension Statements
The aspect oriented features of e allows different language
constructs to be extended after their initial definition
The constructs that can be extended are:
structs/units, methods/TCMs, enumerated types,
coverage groups and items, and events
Methods are extended using keywords of is empty, is
undefined, is first, is only, and is also
Structs can also be extended using the extend mechanism
21
Concurrency and Thread Control
The two fundamental concepts in concurrent programming are processes and
resources
A process refers to sequential execution of a task and has its own thread
of execution
Resources refer to the necessary elements required for executing a process
(i.e. memory space, I/O devices, etc.)
To support concurrent programming, a language should provide utilities for
supporting:
Concurrently running threads
Thread synchronization
Starting new threads
Suspending a running thread
Ending (removing) a running thread
Restarting a suspended thread
The e programming language has full support for concurrent programming
22
Events
Events are used to synchronize execution between threads
The event keyword is used to define an event
Events can be defined by temporal expressions that are part
of the e language
The e language defines a number of predefined events that
are emitted by the e program execution environment.
23
Temporal Expressions
Temporal Expressions are used to describe temporal behavior using
events and temporal operators
A temporal expression is evaluated at every occurrence of its sampling
event
A sampling period is the time between current occurrence of a
sampling event and the previous occurrence of a sampling event
TE can be used like assertions in HDL (PSL or SVA)
24
Time Consuming Methods (TCMs)
Time consuming methods (TCMs) are methods that
consume simulation time
TCMs are used to synchronize processes in an e program
with processes or events in the DUT(triggered by events)
TCMs are e methods that are similar to Verilog tasks and
VHDL processes
Each TCM has a sampling event
To support concurrent programming, the e language
provides:
Concurrency Actions: start, first of, all of
Synchronization Actions: wait, sync
25
Constrained Random Generation
Constraints are statements that restrict values assigned to
data items by test generation
The constrained random generation feature in e randomly
creates a struct hierarchy for data objects and assigns
random values to its scalar fields
They are declared within a struct and influence the
generation of values for data items within the struct and its
subtree
26
Constrained Random Generation (Cont’d)
The generation order is (recursively):
Allocate the new struct
Call pre_generate()
Perform generation
Call post_generate()
27
HDL Simulator Interface
e provides extensive support for HDL simulator access
Signals in the hardware simulator can be accessed and
modified directly from an e program
e provides the predefined event sim to synchronize
operation with the HDL simulator
When driving HDL signals from an e program, it is
possible to use force and release statements to assign and
remove the assignment of a value to an HDL signal
The e compiler automatically creates the necessary
interface to the HDL simulator
28
Units
Unit is very similar to struct
Units are generated in Pre-run generation phase
Units are static and structs are dynamic
Units are the basic structural blocks for creating verification modules
(verification cores) that can easily be integrated together to test larger
Unit created during start of the simulation and stays until the end of
simulation
Like structs they are compound data types that contain fields, methods
and other members
Using units rather than structs can enhance runtime performance
Test bench components are implemented as units
29
e-Ports
A port is an e unit member that makes a connection
between an e unit and its interface to another internal or
external entity
There are two ways to use ports:
Internal ports (e 2 e ports) connect an e unit to another
e unit
External ports connect an e unit to a simulated object
Can only be declared inside units
Have one of in‚ out‚ or inout directions
Are accessed by appending “$” to the reference name (i.e.
data$ is the value of port data)
30
Packing
We want to convert complex data structures to a format
which will allow us to send the data to the DUV
The user defines what will and will not be packed
A common packing operation is serializing the contents of
a struct data object
The syntax for pack() method is:
result = pack(option: pack_options‚ item1:
expression,.....,itemn: expression);
31
Packing (Cont’d)
packing.low packing.high
data_packed_low = pack(packing.low, opcode, operand) ; data_packed_high = pack(packing.high, opcode, operand) ;
32
Unpacking
Unpacking is the reverse operation of packing
The syntax for the unpack() method is:
unpack(option: pack_options‚ serial_data: expression‚
item1: expression,.....,itemn: expression);
33
Unpacking (Cont’d)
unpacking.high
unpack(packing.high, packed_data, inst) ;
34
Functional coverage
Completly under user control
Measures the percentage of functionality verified
A metric to measure the DUV’s readiness for tape out:
Have we tested all features?
Which features haven’t been tested?
A useful tool in test bench debugging:
Do the checkers work?
35
Specman
Specman Elite is the tool from Verisity (now Cadence) that
simulates ‘e’ code stand-alone or also with HDL simulator
Specman is the tool/compiler/debugger for e
Interfaces with the simulator for running the tests and
verifying the results
36
example
Hello World Code
$specman -c "load hello.e; test;"
37
The Specman-Modelsim Interface
38
e Reuse Methodology (eRM)
A methodology for use of the Verisity 'e' language and the
'specman' tool to create verification components and test
environments
e Reuse Methodology (eRM) has been used as the basis for
the Open Verification Methodology (OVM) and Universal
Verification Methodology (UVM)
39
Reusable Verification Components (eVC)
An eVC is an e Verification Component
It is a ready-to-use, configurable verification environment, typically
focusing on a specific protocol or architecture(such as Ethernet, PCI,
USB)
Each eVC consists of a complete set of elements for stimulating,
checking, and measuring coverage information for a specific protocol or
architecture
You can apply the eVC to your device under test (DUT) to verify your
implementation of the eVC protocol or architecture
eVCs expedite creation of a more efficient testbench for your DUT
They can work with all HDL simulators that are supported by Specman
Elite
40
References
S. Iman and S. Joshi, The e Hardware Verification Language. Norwell,
MA,USA: Kluwer Academic, 2004.
S. Palnitkar, Design Verification with e. Prentice Hall PTR,2003.
Preliminary e Language Reference Draft,2003.
Galpin, Darren, Cormac Driver, and Siobhán Clarke. "Modelling
hardware verification concerns specified in the e language: an
experience report." ,ACM, 2009.
Kuhn, Tommy, et al. "Object oriented hardware synthesis and
verification." ,IEEE, 2001.
Edwards, Stephen A. "Design and Verification languages." (2004).
41
View publication stats
