e

e is a domain-specific language for functional verification of hardware. It is not a language for describing chips - Verilog and VHDL already do that - but a language for describing how to attack a chip: how to generate legal-but-nasty stimulus, how to check that the design responded correctly, and how to measure whether the verification effort has actually covered the interesting cases. When e appeared in the mid-1990s, all three of those jobs were typically done with hand-written directed tests in C or Verilog. e replaced them with declarative constraints, temporal expressions, and coverage groups, and in doing so it helped define what “functional verification” means as a discipline.

The language is standardized as IEEE 1647, and its reference implementation is Cadence’s Specman.

History and Origins

e was first developed in 1992 in Israel by Yoav Hollander as the input language for a tool he was building called Specman. Amos Noy, Yaron Kashai, and Guy Mosenson are credited with helping shape the language. Specman consumed e programs and used them to automatically generate the stimulus needed to functionally verify a hardware design - a sharp departure from the directed-test practice of the day.

In 1995, Hollander founded InSpec Software, later renamed Verisity, reportedly with Amos Noy, to commercialize the tool. Specman was introduced commercially at the 1996 Design Automation Conference. The timing was good: chip complexity was outrunning the ability of engineering teams to write enough directed tests by hand, and the “verification gap” was becoming the dominant schedule risk in ASIC projects.

The name is usually explained as “English minus minus” - a joke at the expense of C++, and a claim about readability. This account is widely repeated in secondary sources rather than documented in a primary Verisity publication, so treat it as folklore rather than fact.

Verisity went public on Nasdaq in 2001, reportedly raising roughly $23 million, and was acquired by Cadence Design Systems in an all-cash transaction valued at approximately $315 million, completed in April 2005. Hollander is reported to have become CTO of the resulting Cadence verification division.

Design Philosophy

e was built around a single observation: a verification environment is never finished, and it is always being modified by people who did not write it. A verification IP component might be developed by one team, dropped into a block-level environment by a second, and then bent into shape for a chip-level environment by a third - none of whom can safely edit the original source.

The answer e chose was aspect-oriented programming. Rather than subclassing or editing, an engineer extends existing types in place, from a separate file:

<'
extend packet {
    !timestamp : uint;
    post_generate() is also {
        timestamp = sys.time;
    };
};
'>

The extend construct adds fields, adds constraints, and layers extra behaviour onto an existing method (is also, is first, is only) without touching the file that declared it. Whole test scenarios are written this way: a base environment stays pristine, and each test is a thin aspect that constrains it differently. This is the feature e users most often cite as the reason they never migrated to SystemVerilog, which has no direct equivalent in its standard language constructs.

The second pillar is declarative constraint solving. In e, you do not write code that produces stimulus; you describe the space of legal stimulus and let the generator sample it:

<'
struct packet {
    %kind    : [ CTRL, DATA, IDLE ];
    %len     : uint (bits: 8);
    %payload : list of byte;

    keep payload.size() == len;
    keep soft len in [1..64];

    when CTRL packet {
        keep len < 8;
        keep payload.size() == len;
    };
};
'>

Two things are worth noting. keep soft states a preference rather than a requirement - it is dropped automatically when it conflicts with a hard constraint, which is what makes layered test aspects composable. And when CTRL packet is when-subtyping: a subtype determined by the value of a field rather than by an explicit class hierarchy, so the constraints and fields that only make sense for control packets exist only on control packets.

The % prefix marks a field as part of the physical bit-level layout for packing and unpacking against the design under test - a small but telling detail about what the language was built for.

Key Features

The temporal layer is what makes protocol checking readable. Events are defined over simulation time and composed into sequences:

<'
extend bus_agent {
    event clk is rise('~/top/clk')@sim;
    event req is rise('~/top/req')@clk;
    event ack is rise('~/top/ack')@clk;

    expect @req => {[1..3]; @ack} @clk
        else dut_error("no ack within 3 cycles of req");
};
'>

Coverage is declared in the same file, next to the thing being covered, rather than in a separate coverage database configuration:

<'
extend packet {
    event sent;
    cover sent is {
        item kind;
        item len using ranges = {
            range([1..8],   "short");
            range([9..64],  "long");
        };
        cross kind, len;
    };
};
'>

Note also the <' and '> delimiters: e code is embedded in code segments inside a .e file, a convention inherited from the language’s early habit of living alongside other text.

Evolution

e’s trajectory is unusual: it went from a single vendor’s proprietary language to an open IEEE standard while remaining, in practice, a single vendor’s language.

Verisity donated the temporal subset of e to Open Verilog International in May 2000. In 2002 it released eRM, the e Reuse Methodology, which defined how to build interoperable e Verification Components (eVCs). eRM was arguably the more consequential contribution: its reuse model was absorbed into the Universal Reuse Methodology, then OVM, and ultimately into UVM, the methodology that most of the chip industry uses today, whatever language it writes in.

In 2003, the IEEE Design Automation Standards Committee approved a project to base a verification language standard on e. The result, IEEE 1647-2006, was published in 2006, with revisions in 2008, 2011, 2016, and 2019. The 2019 edition remains the active standard.

On the Cadence side, e gained UVM-e, a native e implementation of the UVM methodology integrated into Specman, and UVM-ML, an open-source multi-language layer that lets e components sit in the same testbench as SystemVerilog and SystemC ones.

Current Relevance

e lost the mainstream to SystemVerilog. When the constrained-random and coverage ideas that e pioneered were folded into IEEE 1800, the industry consolidated on a single language that also described hardware, and new projects overwhelmingly started there. e is best described today as dormant rather than dead: the standard is maintained, Cadence continues to ship and train on Specman, but the language is not attracting new greenfield adoption.

The installed base, however, has proven remarkably sticky. In a September 2020 interview, AMIQ EDA’s CEO reported more than 1,000 active users writing e testbenches with the company’s DVT Eclipse IDE. The reason usually given is not inertia but capability: e’s aspect-oriented features, soft constraints, and when-subtyping have no clean SystemVerilog equivalent, so a migration is a rewrite rather than a translation. Verification environments representing many engineer-years of accumulated corner cases are not rewritten casually.

Practical realities for anyone encountering e today:

• Tooling is commercial. Running e requires Cadence Specman under a paid license. There is no open-source compiler or interpreter, and no official Docker image, so e cannot be tried casually the way most languages on this site can.
• Learning material is thin outside vendor channels. The IEEE 1647 standard, Cadence documentation and training, and a handful of books and conference papers are essentially the whole corpus.
• You will meet it in maintenance. Most engineers who learn e in the 2020s do so because they inherited an environment, not because they chose the language.

Why It Matters

e’s significance is out of all proportion to its current user count. Most of the ideas that define modern functional verification appeared in early commercial form here - alongside contemporaries such as Synopsys Vera - including constrained-random stimulus generation as the default rather than the exception, functional coverage as a first-class language construct rather than a tool feature, temporal assertions over protocol behaviour, and reusable verification components with a published reuse methodology.

SystemVerilog absorbed most of that agenda, and UVM descends through OVM and URM from e’s own eRM. In that sense the language succeeded so thoroughly that it made itself optional - the industry adopted e’s model of verification without adopting e. What SystemVerilog did not absorb was the aspect-oriented core, which remains the strongest technical argument for the language and the reason a determined minority of verification engineers are still writing extend in 2026.

Sources: e (verification language) - Wikipedia, IEEE SA - IEEE 1647, Cadence completes acquisition of Verisity - EE Times, Verisity announces eRM - Design & Reuse, Verisity donates temporal language to OVI - Design & Reuse, Don’t You Forget About “e” - SemiWiki, Specman Elite datasheet - Cadence