My Clark Kent Moment – How I Discovered Aspect Oriented Programming in e (IEEE 1647)

Growing up on VHDL, moving on to Verilog and then to SystemVerilog, I eventually discovered e (IEEE 1647)

Initially I thought: "What is the fuss all about?"

While exploring the language during the development of the cowbell videos, it hit me -- I started to recognize the power of Aspect Oriented Programming (AOP). Indeed, it is the antidote to Verification-Kryptonite!

Let me explain my newfound capabilities. When you verify complex systems you will certainly end up in situations where you have to deal with unanticipated changes to the original requirements, as well unanticipated requirements of your verification environment. These are just two of many areas where AOP can provide enormous flexibility and efficiency.

Using AOP you can take any environment, and with a flip of a finger change the behavior of any component, transaction type, coverage model or the entire system. The best part is, this can all be done without altering your existing code base. Therefore, code maintenance does not need to compete with flexibility any longer.

Consider the following situation. It is summer and the project is well underway. You are writing and running some tests and you encounter a bug. In your team, the roles and responsibilities are clearly separated and you need information that the current verification environment does not provide. However, the person owning the verification environment is on vacation.

This dilemma can have serious consequences on productivity.

Even if a backup resource for the verification environment is available it would still take time and effort to communicate what you need. In addition, you are introducing risk by altering code, and potentially adding bugs. Lastly, you are dependent on another player the team. Altogether you are in a bad place.

With AOP, however, you can mitigate the risk, break the dependencies, and create flexibility. In fact, you can add the required functionality to the verification environment from the outside, without having to bother anyone, and without touching the existing, stable environment.

To be more specific, let's say you need to log the start time when an APB transaction is driven. Traditionally, you would have to add a field to store the value of the transaction in the sequence item file, and then you have to change the method call in the BFM file. Instead, with AOP, you just create a new extension file for your particular debug purpose. For example:

// apb_trans_s.e (abridged file) - sequence item definition - unaltered

struct apb_trans_s like any_sequence_item {

   addr : uint;
   data : uint;

   ...
}


// apb_master_bfm.e (abridged file) - BFM definition - unaltered

unit apb_master_bfm like apb_bfm {

   ...

   drive_transaction_address (cur_transaction : apb_trans_s)

   @tf_phase_clock is {
      ...
   }
}


// debug_start_time.e - (entire file) - extension with AOP

extend apb_trans_s {
   start_time:time;

};

extend apb_master_bfm {

   !history_list: list of
   apb_trans_s;

   drive_transaction_address () @clk is first {

      cur_trans.start_time = sys.time;
      history_list.add(cur_trans);

   };

};

In this example you added a new field, start_time, to the sequence item and you added additional functionally to the beginning of the drive_transaction_address method of the BFM.

After you load this extension file in your next simulation run, you automagically gain new features in your environment using AOP without introducing risk to other users and without depending on another person.

After trying this on some examples I felt as if my inner Superman had been unleashed and I had gained a new superpower.

Unleash your superpower too, with AOP.

Axel Scherer
Incisive Product Expert Team
Twitter, @axelscherer