{"history":[],"article":{"id":"60368078-7807-4e0b-9041-34146624e9de","title":"E (verification language)","slug":"e-verification-language","content":":::summary\n**Name:** e \n**File Ext:** .e \n**Paradigm:** [Aspect-oriented](https://bliptext.com/articles/aspect-oriented-programming) \n**Released:** 1992 \n**Designer:** Yoav Hollander \n**Latest Release Version:** IEEE 1647-2019 \n**Latest Release Date:** June 13, 2019 \n**Website:** [TWiki @ eda.org](https://bliptext.com/articles/undefined) \n:::\n\n# \n**e** is a hardwar**e** v**e**rification languag**e** (HVL) which is tailor**e**d to impl**e**m**e**nting highly fl**e**xibl**e** and r**e**usabl**e** v**e**rification t**e**stb**e**nch**e**s.\n\n# History\ne was first developed in 1992 in Israel by Yoav Hollander for his [Specman](https://bliptext.com/articles/specman) software.\nIn 1995 he founded a company, InSpec (later renamed [Verisity](https://bliptext.com/articles/verisity)), to commercialize the software.\nThe product was introduced at the 1996 [Design Automation Conference](https://bliptext.com/articles/design-automation-conference).\nVerisity has since been acquired by [Cadence Design Systems](https://bliptext.com/articles/cadence-design-systems).\n\n# Features\nMain features of e are:\n\n# Language Features\nThe e language uses an [aspect-oriented programming](https://bliptext.com/articles/aspect-oriented-programming) (AOP) approach, which is an extension of the [object-oriented programming](https://bliptext.com/articles/object-oriented-programming) approach to specifically address the needs required in functional verification.\nAOP is a key feature in allowing for users to easily bolt on additional functionality to existing code in a non-invasive manner.\nThis permits easy reuse and code maintenance which is a huge benefit in the hardware world, where designs are continually being tweaked to meet market demands throughout the project lifecycle.\nAOP also addresses cross cutting concerns (features that cut across various sections of the code) easily by allowing users to extend either specific or all instances of a particular struct to add functionality.\nUsers can extend several structs to add functionality related to a particular feature and bundle the extensions into a single file if desired, providing for more organized file partitioning.\n\n## Comments\nExecutable e code is enclosed within code-segment markers <' and '>:\n\n### Example\nAnything outside the markers is a comment\n<' extend sys {\n// This is a comment Verilog style\n-- This is a comment in VHDL style\npost_generate is also {\nout(\"... and everything else within the markers is executable code.\");\n}; }; '>\n\n## Classes\ne also has two kinds of classes:\nA class may contain fields, methods, ports and constraints.\nFields can be of type integer, real, enum, string and even complex objects.\nThe code segment shows a unit called 'environment_u' being instantiated within the e root 'sys'.\nThis environment_u class contains a list of 5 packet_s objects and this packet_s class contains two fields and a method.\n\n### Example\n<' // This is a dynamic class with two fields\nstruct packet_s {\nfield0: uint (bits: 32); // This field is called 'field0' and is a // 32 bit wide unsigned integer.\nfield1: byte; // This field is called 'field1' and is a byte.\n// This method is called once a packet_s object has been generated\npost_generate is also {\nout(field0); // Printing the value of 'field0'\n}; };\n// This is a static class with a list of five packet struct\nunit environment_u {\nmy_pkt[5]: list of packet_s;\n};\n// sys is the root for every e environment and instantiates the 'test_env' object\nextend sys {\ntest_env: environment_u is instance;\n}; '>\n\n## Randomization\nIn e each field is randomized by default.\nField randomization can be controlled by hard constraints, soft constraints or even be turned off completely.\nSoft constraints are used as the default constraints, and may be automatically overridden by the test layer if a conflict occurs.\nOtherwise it behaves like a regular constraint.\n\n### Example\n<' struct my_pkt_s {\ndestination_address: uint (bits: 48); // this field is randomized and is not constrained.\ndata_payload : list of byte;\n!parity_field : uint (bits: 32); // '!' prevents the parity_field from being randomized.\nkeep soft data_payload.size in [64..1500]; // a soft constraint, used to provide a default randomization\nkeep data_payload.size not in [128..256]; // this is a hard constraint\n}; '>\n\n## Assertions\ne supports assertions with temporal expressions.\nA temporal expression is used at the same syntactic level as fields and methods and is thereby declarative by nature.\nA temporal expression describes timed behavior.\n\n### Example\n<' unit temporal_example_u {\nevent 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.\nexpect @a => {@b;@c}\n}; '>\n\n## Coverage\ne supports coverage that are grouped according to their sampled event and those groups are internally structured with items.\nItems can be simple items or complex items such as crossed items or transitional items.\n\n### Example\nunit coverage_example_u {\nevent cov_event_e; // collecting coverage will be tied to this event\ncover cov_event_e is {\nitem a: uint (bits: 4); // this item has 16 buckets from 0 to 15\nitem b: bool; // this item has two buckets: TRUE and FALSE\ncross 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\n// transitioning each TRUE - FALSE combination\n}; };\n\n## Messaging & Reporting\nMessaging within e can be done with various methods.\n\n### Example\nunit message_example_u {\nexample_message_method is {\nout(\"This is an unconditional, unformatted output message.\");\noutf(\"This is an unconditional, formatted output message displaying in HEX %x\",15);\nprint \"This is an unconditional message.\";\nmessage( 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.\" );\nmessagef( LOW, \"This conditional output is formatted %x.\",15 );\n}; };\n\n## Interfacing With Other Languages\nAn e testbench is likely to be run with RTL or higher-level models.\nBearing this in mind, e is capable of interfacing with [VHDL](https://bliptext.com/articles/vhdl), [Verilog](https://bliptext.com/articles/verilog), [C](https://bliptext.com/articles/c-programming-language), [C](https://bliptext.com/articles/c-programming-language)++ and System[Verilog](https://bliptext.com/articles/verilog).\n\n### Example of an e <-> Verilog Hookup\nThis code is in a signal_map.e file\n<' unit signal_map_u {\n// Define a port named 'a_clk_p'\na_clk_p: in simple_port of bit is instance;\n// Set the port's hdl_path property to point to the 'a_clk' signal in the top-level testbench\nkeep a_clk_p.hdl_path == \"~/testbench_top/a_clk\";\n}; '>\n\n# Aspect-Oriented Programming Support in e\nThe process of functional verification requires to raise the level of abstraction of any Design Under Test (DUT) beyond the RTL level.\nThis necessity calls for a language that is capable of encapsulating data and models, which is readily available in object-oriented languages.\nTo 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.\nAspect-oriented programming in e allows verification engineers to structure their testbench in aspects.\nAn object is therefore the sum of all its aspects, which may be distributed over multiple files.\nThe following sections illustrate basic aspect-oriented mechanisms in e.\n\n## Subtyping Mechanism\nSubtyping is the prime example of what object-oriented languages without aspect-oriented features can not accomplish.\nSubtyping allows a verification engineer to add functionality to an already defined/implemented class without having to derive from a base class.\nThe following code shows the original implementation of a base-class and how it is extended.\nOnce the extension took place, all base-class objects contain the extensions as well.\nThe 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.\n\n### Subtyping Mechanism Example\nsubtyping_example.e <'\n// This enum type definition is used to declare the subtypes ODD and EVEN\ntype ctrl_field_type_t: [ODD, EVEN];\nunit base_ex_u {\n// The subtype_field is the determinant field which calculation is being applied\nsubtype_field: ctrl_field_type_t;\ndata_word : uint (bits: 32);\nparity_bit : bit;\n// Subtyping the ODD type\nwhen ODD'subtype_field base_ex_u {\n// This is a simple constraint that XORs the index bit 0 of data_word and increments that value\nkeep parity_bit == (data_word[0:0] ^ data_word[0:0] + 1);\n};\n// Subtyping the EVEN type\nwhen EVEN'subtype_field base_ex_u {\n// This constraint is the same as above, however the increment is not done\nkeep parity_bit == (data_word[0:0] ^ data_word[0:0]);\n}; }; '>\n\n## Extending Methods\nThe 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.\n\n### Method Extension Example\nThis code is in file1.e <'\nunit aop_example_u {\nmeth_ext is {\nout(\"This is the original method implementation.\");\n}; }; '>\nThis code is in file2.e <'\nextend aop_example_u {\nmeth_ext is first {\nout(\"This method extension is executed before the original method implementation.\");\n};\nmeth_ext is also {\nout(\"This method extension is executed after the original method implementation.\");\n}; }; '>\n\n# Sources","current_revision":null,"created_by":"kACnuQmH5k9Nr5VNVEpVeg7XpvUmMctD","created_at":"2025-01-26T08:55:52.336Z","updated_at":"2025-01-26T08:55:52.336Z","search_vector":"'e':1 'languag':3 'verif':2","search_content":" \n**Name:** e \n**File Ext:** .e \n**Paradigm:** [Aspect-oriented](https://bliptext.com/articles/aspect-oriented-programming) \n**Released:** 1992 \n**Designer:** Yoav Hollander \n**Latest Release Version:** IEEE 1647-2019 \n**Latest Release Date:** June 13, 2019 \n**Website:** [TWiki @ eda.org](https://bliptext.com/articles/undefined) \n \n\n# \n**e** is a hardwar**e** v**e**rification languag**e** (HVL) which is tailor**e**d to impl**e**m**e**nting highly fl**e**xibl**e** and r**e**usabl**e** v**e**rification t**e**stb**e**nch**e**s.\n\n# History\ne was first developed in 1992 in Israel by Yoav Hollander for his [Specman](https://bliptext.com/articles/specman) software.\nIn 1995 he founded a company, InSpec (later renamed [Verisity](https://bliptext.com/articles/verisity)), to commercialize the software.\nThe product was introduced at the 1996 [Design Automation Conference](https://bliptext.com/articles/design-automation-conference).\nVerisity has since been acquired by [Cadence Design Systems](https://bliptext.com/articles/cadence-design-systems).\n\n# Features\nMain features of e are:\n\n# Language Features\nThe e language uses an [aspect-oriented programming](https://bliptext.com/articles/aspect-oriented-programming) (AOP) approach, which is an extension of the [object-oriented programming](https://bliptext.com/articles/object-oriented-programming) approach to specifically address the needs required in functional verification.\nAOP is a key feature in allowing for users to easily bolt on additional functionality to existing code in a non-invasive manner.\nThis permits easy reuse and code maintenance which is a huge benefit in the hardware world, where designs are continually being tweaked to meet market demands throughout the project lifecycle.\nAOP also addresses cross cutting concerns (features that cut across various sections of the code) easily by allowing users to extend either specific or all instances of a particular struct to add functionality.\nUsers can extend several structs to add functionality related to a particular feature and bundle the extensions into a single file if desired, providing for more organized file partitioning.\n\n## Comments\nExecutable e code is enclosed within code-segment markers :\n\n### Example\nAnything outside the markers is a comment\n \n\n## Classes\ne also has two kinds of classes:\nA class may contain fields, methods, ports and constraints.\nFields can be of type integer, real, enum, string and even complex objects.\nThe code segment shows a unit called 'environment_u' being instantiated within the e root 'sys'.\nThis environment_u class contains a list of 5 packet_s objects and this packet_s class contains two fields and a method.\n\n### Example\n \n\n## Randomization\nIn e each field is randomized by default.\nField randomization can be controlled by hard constraints, soft constraints or even be turned off completely.\nSoft constraints are used as the default constraints, and may be automatically overridden by the test layer if a conflict occurs.\nOtherwise it behaves like a regular constraint.\n\n### Example\n \n\n## Assertions\ne supports assertions with temporal expressions.\nA temporal expression is used at the same syntactic level as fields and methods and is thereby declarative by nature.\nA temporal expression describes timed behavior.\n\n### Example\n {@b;@c}\n}; '>\n\n## Coverage\ne supports coverage that are grouped according to their sampled event and those groups are internally structured with items.\nItems can be simple items or complex items such as crossed items or transitional items.\n\n### Example\nunit coverage_example_u {\nevent cov_event_e; // collecting coverage will be tied to this event\ncover cov_event_e is {\nitem a: uint (bits: 4); // this item has 16 buckets from 0 to 15\nitem b: bool; // this item has two buckets: TRUE and FALSE\ncross 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\n// transitioning each TRUE - FALSE combination\n}; };\n\n## Messaging & Reporting\nMessaging within e can be done with various methods.\n\n### Example\nunit message_example_u {\nexample_message_method is {\nout(\"This is an unconditional, unformatted output message.\");\noutf(\"This is an unconditional, formatted output message displaying in HEX %x\",15);\nprint \"This is an unconditional message.\";\nmessage( 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.\" );\nmessagef( LOW, \"This conditional output is formatted %x.\",15 );\n}; };\n\n## Interfacing With Other Languages\nAn e testbench is likely to be run with RTL or higher-level models.\nBearing this in mind, e is capable of interfacing with [VHDL](https://bliptext.com/articles/vhdl), [Verilog](https://bliptext.com/articles/verilog), [C](https://bliptext.com/articles/c-programming-language), [C](https://bliptext.com/articles/c-programming-language)++ and System[Verilog](https://bliptext.com/articles/verilog).\n\n### Example of an e Verilog Hookup\nThis code is in a signal_map.e file\n \n\n# Aspect-Oriented Programming Support in e\nThe process of functional verification requires to raise the level of abstraction of any Design Under Test (DUT) beyond the RTL level.\nThis necessity calls for a language that is capable of encapsulating data and models, which is readily available in object-oriented languages.\nTo 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.\nAspect-oriented programming in e allows verification engineers to structure their testbench in aspects.\nAn object is therefore the sum of all its aspects, which may be distributed over multiple files.\nThe following sections illustrate basic aspect-oriented mechanisms in e.\n\n## Subtyping Mechanism\nSubtyping is the prime example of what object-oriented languages without aspect-oriented features can not accomplish.\nSubtyping allows a verification engineer to add functionality to an already defined/implemented class without having to derive from a base class.\nThe following code shows the original implementation of a base-class and how it is extended.\nOnce the extension took place, all base-class objects contain the extensions as well.\nThe 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.\n\n### Subtyping Mechanism Example\nsubtyping_example.e \n\n## Extending Methods\nThe 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.\n\n### Method Extension Example\nThis code is in file1.e \nThis code is in file2.e \n\n# Sources","revisionCount":0},"hasMore":false,"nextCursor":null}