Knowledge Center
Knowledge Center


Hardware Verification Language


The e language is an early hardware verification language (HVL) originally developed by Yoav Hollander. It was standardized as IEEE 1647 in 2006. The language implements reusable verification testbenches.

Key Features

  • Supports random and constrained-random stimulus generation
  • Supports temporal language that can be used for writing assertions
  • Can run in compiled mode or in interpreted mode, and does not force elaboration
  • e Reuse Methodology (eRM) has been used as the basis for the Open Verification Methodology (OVM) and Universal Verification Methodology (UVM)
  • DUT-neutral language: 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 (using the UVM Acceleration for e Methodology)

Aspect-Oriented Programming Support
The e language uses an aspect-oriented programming (AOP) approach, which is an extension of the object-oriented programming approach, to address functional verification needs. AOP 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.

AOP allows users to easily bolt on additional functionality to existing code in a non-invasive manner. This permits easy reuse and code maintenance-a huge benefit in the hardware world, where designs are continually being tweaked throughout the project lifecycle to meet market demands. AOP also addresses cross-cutting concerns (features that cut across various sections of the code) by allowing users to easily extend either specific or all instances of a particular struct to add functionality. Users can extend several structs to add functionality related to a particular feature and bundle the extensions into a single file for more organized file partitioning. Thus, it enables far easier reuse and much more rapid “extendability” for derivative environments (without changing and re-verifying every module).

Also, debug cycle productivity is much higher with e due to its automatic support for parallel compilation, full debug visibility into optimized compiled code, and full flexibility for loading/compiling new code.

Constrained-Random Subtyping Mechanism
Subtyping is the prime example of what object-oriented languages cannot accomplish without aspect-oriented features. Subtyping allows a verification engineer to add functionality to an already defined/implemented class without having to derive from a base class.

“Infinity-Minus” 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 default, and may be automatically overridden by the test layer if a conflict occurs. Otherwise it behaves like a regular constraint.

Reseeding and Dynamic Loading
Simulation engines support session persistency in the sense that the entire simulation state can be saved to disk and later resumed from the same point in a different process, possibly multiple times. This means that you could run a simulation up to a certain point, save its state, and resume it in multiple processes later on.

To take advantage of this, one approach is to enable the random seed to be changed after a simulation state is restored. The new seed would cause the test scenarios to change from the restore point forward, due to different results of random generation. This approach is called reseeding, and can be applied to all verification environments that use random generation for creating test scenarios.

Another approach would be to load additional files after the simulation has been restored. The loaded code could contain constraints and additional functionality that could change the behavior of the resulting test scenario from the load point onward. This approach is called dynamic loading.

When used together, dynamic loading and reseeding dramatically improve verification productivity.

Built-In Temporal and Data Assertions
e supports assertions with temporal expressions, which describe timed behavior. A temporal expression is used at the same syntactic level as fields and methods, and is thereby declarative by nature.

Built-In Functional Coverage
e supports coverage that is grouped according to sampled event, and those groups are internally structured with items. Items can be simple or complex, such as crossed items or transitional items.

Aspect-Oriented Programming with the e Verification Language: A Pragmatic Guide for Testbench Developers (Systems on Silicon)

The e Hardware Verification Language (Information Technology: Transmission, Processing & Storage)

Related People

Related Entities

Related Technologies