• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Verification
  3. e Templates and Aspect Oriented Programming
teamspecman
teamspecman

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
Specman
EDA
e
team specman
Aspect Oriented Programming
AOP
IES-XL

e Templates and Aspect Oriented Programming

21 Sep 2010 • 2 minute read

In a recent blog - "e Templates: A Nifty Way To Create Reusable Code", Corey Goss wrote about the useful feature of template types, which lets you write reusable code.

In this post I'll show how the combination of templates and aspect-oriented programming (AOP) allows you to make such reusable code even more flexible. This combination is indeed unique for the e language. As you surely know, AOP allows you to extend an already existing struct or unit, and add or modify some of its members, for example add a new field or modify a method (with "is only" or "is also").

For templates, you can also extend a specific instance of an existing template. So, in this case AOP allows you not only to separate your struct into "aspects" (when the fields, methods, and events of each aspect can be defined in a different module), but also to use the same familiar "extend ..." syntax to distinguish between what is common to all instances and what is specific to a given instance.

Let's use the slightly modified example from Corey's post to illustrate this:

template unit scoreboard of (<T'type>) {

    // Instantiate the TLM analysis ports to receive items for adding items to the scoreboard and checking
    add_item: in interface_port of tlm_analysis of <T'type> using prefix=add_item_ is instance;
    check_item: in interface_port of tlm_analysis of <T'type> using prefix=check_item_ is instance;

    // The actual scoreboard list
   !sblist: list of <T'type>;  

   // Implement the _write() method of the TLM analysis port
   add_item_write(p: <T'type>) is {
      message(NONE, "scoreboard added item: ", p);
      sblist.push(p);
   };

   // Implement the _write() method of the TLM analysis port
   check_item_write(p: <T'type>) is { 
      if (deep_compare_physical(p, sblist[0], 10).is_empty()) then {sblist.delete(0);};
      message(NONE, "scoreboard checked item: ", p);
   };           
};

Now suppose we want to slightly modify the behavior of scoreboard for a specific transaction type, say packets. It would preserve the same logic, but it would use a custom comparison method for packets. This can be done simply by adding the following code:

extend scoreboard of packet_s {
   // Implement the _write() method of the TLM analysis port
   check_item_write(p:  packet_s) is only { 
      if (p.compare(sblist[0])) then {sblist.delete(0);};
      message(NONE, "scoreboard checked item: ", p);
   };           
};


In this example we have modified a method of a specific template instance, using "is only". You can also add fields, methods, or do any other change to a template instance, that you are used to do when extending a struct.

If you are familiar with template types in other languages, such as C++ or SystemVerilog, you may wonder whether this capability is different from the template specialization feature provided by some of those languages. The answer is yes. In C++ you can write a separate implementation for a specific template instance, but then you fully replace the generic code written for the template with the new code. In e, as we've just shown, you can keep the template code which is common for all instances, and make just additions or modifications (if any needed) for specific instances.

Yuri Tsoglin

Specman R&D e Language team.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information