e (verification language)

Executable e code is enclosed within code-segment markers <' and '>:

Anything outside the markers is a comment
<'
extend sys {
  // This is a comment Verilog style
  -- This is a comment in VHDL style
  post_generate() is also {
    out("... and everything else within the markers is executable code.");
  };
};
'>

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.

A class may contain fields, methods, ports and constraints. Fields can be of type integer, real, enum, string and even complex objects. The code segment shows a unit called 'environment_u' being instantiated within the e root 'sys'. This environment_u class contains a list of 5 packet_s objects and this packet_s class contains two fields and a method.

<'
// This is a dynamic class with two fields
struct packet_s {
  field0: uint (bits: 32);   // This field is called 'field0' and is a 
                            // 32 bit wide unsigned integer.
  field1: byte;             // This field is called 'field1' and is a byte.
  
  // This method is called once a packet_s object has been generated
  post_generate() is also { 
    out(field0);            // Printing the value of 'field0'
  };
};

// This is a static class with a list of five packet struct
unit environment_u {
  my_pkt[5]: list of packet_s;
};

// sys is the root for every e environment and instantiates the 'test_env' object
extend sys {
  test_env: environment_u is instance;
};
'>

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.

<'
struct my_pkt_s {
  destination_address: uint (bits: 48);   // this field is randomized and is not constrained.
  data_payload       : list of byte;     
  !parity_field      : uint (bits: 32);   // '!' prevents the parity_field from being randomized.
  
  keep soft data_payload.size() in [64..1500];  // a soft constraint, used to provide a default randomization
  keep data_payload.size() not in [128..256];   // this is a hard constraint
};
'>

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.

<'
unit temporal_example_u {
  event a;   // declaring an event 'a'
  event b;   // declaring an event 'b'
  event c;   // declaring an event 'c'
  
  // This assertion expects that the next cycle after event a
  // has been detected that event b followed by event c occurs.
  expect @a => {@b;@c}
};
'>

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.

unit coverage_example_u {
  event cov_event_e;   // collecting coverage will be tied to this event

  cover cov_event_e is {
    item  a: uint (bits: 4);   // this item has 16 buckets from 0 to 15
    item  b: bool;            // this item has two buckets: TRUE and FALSE
    cross a, b;               // this item contains a cross multiplication matrix of a and b
    trans b;                  // this item is derived of item b and has four buckets
                              // transitioning each TRUE - FALSE combination
  };
};

Messaging within e can be done with various methods.

unit message_example_u {
  example_message_method() is {
    out("This is an unconditional, unformatted output message.");
    outf("This is an unconditional, formatted output message displaying in HEX %x",15);
    print "This is an unconditional message.";
    message( LOW, "This is a conditional message, usually tied to a message logger. ",
                  "You can also concatenate strings like this and even add objects like ",me,
                  " in this output." );
    messagef( LOW, "This conditional output is formatted %x.",15 );
  };
};

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.

// 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 {
  // Define a port named 'a_clk_p'
  a_clk_p: in simple_port of bit is instance;
  // Set the port's hdl_path property to point to the 'a_clk' signal in the top-level testbench
  keep a_clk_p.hdl_path() == "~/testbench_top/a_clk";
};
'>

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_example.e
<'
// This enum type definition is used to declare the subtypes ODD and EVEN
type ctrl_field_type_t: [ODD, EVEN];
unit base_ex_u {
  // The subtype_field is the determinant field which calculation is being applied
  subtype_field: ctrl_field_type_t;
  data_word    : uint (bits: 32);
  parity_bit   : bit;
  
  // Subtyping the ODD type
  when ODD'subtype_field base_ex_u {
    // This is a simple constraint that XORs the index bit 0 of data_word and increments that value
    keep parity_bit == (data_word[0:0] ^ data_word[0:0] + 1);
  };

  // Subtyping the EVEN type
  when EVEN'subtype_field base_ex_u {
    // This constraint is the same as above, however the increment is not done
    keep parity_bit == (data_word[0:0] ^ data_word[0:0]);
  };
};
'>

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.

This code is in file1.e
<'
unit aop_example_u {
  meth_ext() is {
    out("This is the original method implementation.");
  };
};
'>

This code is in file2.e
<'
extend aop_example_u {
  meth_ext() is first {
    out("This method extension is executed before the original method implementation.");
  };

  meth_ext() is also {
    out("This method extension is executed after the original method implementation.");
  };
};
'>