E (verification language)
e is a hardware verification language which is tailored to implementing highly flexible and reusable verification testbenches.
History
e was first developed in 1992 in Israel by Yoav Hollander for his Specman software. In 1995 he founded a company, InSpec, to commercialize the software. The product was introduced at the 1996 Design Automation Conference. Verisity has since been acquired by Cadence Design Systems.Features
Main features of e are:- Random and constrained random stimulus generation
- Functional coverage metric definition and collection
- Temporal language that can be used for writing assertions
- Aspect-oriented programming language with reflection capability
- Language is DUT-neutral in that you can use a single e testbench to verify a SystemC/C++ model, an RTL model, a gate level model, or even a DUT residing in a hardware acceleration box
- Can create highly reusable code, especially when the testbench is written following the Universal Verification Methodology
- * Formerly known as e Re-use Methodology
- * UVM e library and documentation can be downloaded here:
Language Features
Comments
Executable e code is enclosed within code-segment markers <' and '>:Example
Anything outside the markers is a comment
<'
extend sys ;
'>
Classes
e also has two kinds of classes:- Dynamic classes are labeled with the keyword 'struct'. Structs are used for creating data that only exists temporarily and may be cleaned by the garbage collector.
- Static classes are labeled with the keyword 'unit'. Units are used for creating the permanent testbench structure.
Example
<'
// This is a dynamic class with two fields
struct packet_s ;
// This is a static class with a list of five packet struct
unit environment_u ;
// sys is the root for every e environment and instantiates the 'test_env' object
extend sys ;
'>
Randomization
In e each field is randomized by default. Field randomization can be controlled by hard constraints, soft constraints or even be turned off completely. Soft constraints are used as the default constraints, and may be automatically overridden by the test layer if a conflict occurs. Otherwise it behaves like a regular constraint.Example
<'
struct my_pkt_s ;
'>
Assertions
e supports assertions with temporal expressions. A temporal expression is used at the same syntactic level as fields and methods and is thereby declarative by nature. A temporal expression describes timed behavior.Example
<'
unit temporal_example_u ;
'>
Coverage
e supports coverage that are grouped according to their sampled event and those groups are internally structured with items. Items can be simple items or complex items such as crossed items or transitional items.Example
unit coverage_example_u ;
Messaging & Reporting
Messaging within e can be done with various methods.Example
unit message_example_u ;
Interfacing With Other Languages
An e testbench is likely to be run with RTL or higher-level models. Bearing this in mind, e is capable of interfacing with VHDL, Verilog, C, C++ and SystemVerilog.Example of an ''e'' <-> Verilog Hookup
// This code is in a Verilog file tb_top.v
module testbench_top;
reg a_clk;
always #5 a_clk = ~a_clk;
initial begin
a_clk = 0;
end
endmodule
This code is in a signal_map.e file
<'
unit signal_map_u ;
'>
Aspect-Oriented Programming Support in ''e''
The process of functional verification requires to raise the level of abstraction of any Design Under Test beyond the RTL level. This necessity calls for a language that is capable of encapsulating data and models, which is readily available in object-oriented languages. To address this need has been designed to be e an object-oriented language and on top of that has been augmented with aspect-oriented mechanisms that facilitate not only writing highly flexible and reusable testbenches, but also helps verification engineers by enabling to patch discovered RTL bugs without having to rewrite or touch any of the already existing code base.Aspect-oriented programming in e allows verification engineers to structure their testbench in aspects. An object is therefore the sum of all its aspects, which may be distributed over multiple files. The following sections illustrate basic aspect-oriented mechanisms in e.
Subtyping Mechanism
Subtyping is the prime example of what object-oriented languages without aspect-oriented features can not accomplish. Subtyping allows a verification engineer to add functionality to an already defined/implemented class without having to derive from a base class. The following code shows the original implementation of a base-class and how it is extended. Once the extension took place, all base-class objects contain the extensions as well. The constraints given in the two different subtypes would usually cause a contradiction, however both subtypes are handled separately and thus each subtype yields a different constraint calculation.Subtyping Mechanism Example
subtyping_example.e
<'
// This enum type definition is used to declare the subtypes ODD and EVEN
type ctrl_field_type_t: ;
unit base_ex_u ;
'>
Extending Methods
The original unit definition is given in file1.e. The aspect-oriented mechanism used in this example shows how to execute code before and after an already implemented method.Method Extension Example
This code is in file1.e
<'
unit aop_example_u ;
'>
This code is in file2.e
<'
extend aop_example_u ;
'>