1. Callbacks have limited scope and cannot easily change the base class implementation.

2. I find myself spending a lot of times coding these callbacks and giving them enough flexibility. There ends up being hundreds of more lines of code that is difficult to read.

3. Even after the callback we still need to change some methods and classes from the base implementation, especially for directed testcases. We use a different compilation flow where certain testbench files are not read in.

I did not reply to Corey’s original comment because my blog post is about SystemVerilog, while his comment was about e (a different language) and AOP (a programming model that does not [yet] exists in SystemVerilog. With all due respect to Corey, I considered it interesting but tangential to the topic at hand.

Callbacks can be used to add more fields, coverage groups (you can’t add coverage points in SV, only groups) or events to an IP. They simply won’t reside in the IP itself but in the callback. Same result, different approach.

The VMM makes several recommendations on where callbacks should be inserted. How is relying on the structure of the IP any better? The methods must be defined at a suitable granularity to allow the additional functionality to be inserted before or after them. How would you know what granularity is needed? You can’t extend a virtual method in the middle — but you can put a callback there. Or a call to an empty virtual method which amounts to the same thing as having a callback. Then, these methods must be virtual. An easy thing to accomplish, however, it does not happen on its own. And how can you ensure that the implementation of all these virtual methods allow you to modify the behavior as you need? So these implicit extension points need to be planned, just like callbacks.

Extensibility does not happen by accident — only by design. Cut & paste of the original implementation of a method, to modify or remove a couple of statements in it, is not extension nor re-use. Functionality that could be removed or overridden could be implemented in VMM using a chain-of-responsibility pattern by stopping at the first callback encountered that claims responsibility for the functionality. The default behavior of the `vmm_callback() macro is to execute all registered callbacks — but that is only one of the possible way to go through the callback registry. Again, same result but different approach.

Callbacks and factories are different approaches to solving the same problem. For a specific problem, a specific solution may yield a little less code than the other. Claims of ease of learning and debugging are easy to make, but harder to substantiate — so I often choose not to make them. The ease-of-use is usually a function of the tool and what you are used to anyway, not something intrinsic.

For extensions, I’ll continue to recommend callbacks, why?

a. They can do structural and procedural extensions.

b. They clearly document the extension points of an IP.

c. They limit the potential side effect of user extensions.

d. SystemVerilog does not support multiple inheritance. Combining multiple orthogonal extensions using inheritance leads to an exponential number of class extensions. Different orthogonal callback extensions can be registered in any combination or order without additional work or complexity.

e. Callback extensions can be dynamically added and removed. It is not necessary to code the dynamic nature of the extensions in the functionality.

As for crossing language boundaries, it is a technical issue. There is no requirement that both sides have to use the same methods and constructs. As long as they have similar semantics, the adaptation of one side’s methods and constructs to the other side is done at the same time as the data is translated. A vmm_channel in SV can connect to a tlm_fifo on the SC side or a vmm_notify can connect to an analysis port, thereby facilitating language interoperability.

The transaction-level interface mechanisms in VMM have been successfully used to verify hundreds of designs without proving to be a limitation. OSCI-TLM was designed for a language that supports multi-inheritance and lacks the built-in notions of concurrency and connectivity. SystemVerilog is inheritenly concurrent and has a well-known connectivity model (modules ports to wires). I guess I’ll reverse my earlier statement and claim that the resulting connectivity model is a lot easier to understand and debug…I always chuckle when I see the large number of slides necessary to explain the TLM mechanism in AVM/OVM presentations. I can explain the VMM channel connectivity in one slide. Ultimately though, both accomplish the same result, using a different approach.

You keep bringing up e and AOP. Many of the OVM features feel like it is trying to be e. Some are really cool and we did not hesitate to acknowledge them. Take the automation macros. When I first saw them, I was really impressed and I was baffled for a while as to how they worked. It took me a couple of days to figure out how to implement them in VMM (it came to me in the shower – go figure!). But I was horrified when I was finally able to look at their implementation in the OVM to discover that they rely on a run-time duplication of the symbol table and that the high-frequency transaction copy/compare/display/pack/unpack methods are interpretive. That must cost quite a bit of memory and run time overhead!

Trying to force-fit a use model that does not “flow” with the underlying language can be counterproductive. It requires a large number of classes and macros to implement (and document and maintain). For example, e has some form of introspection. Adding it to SV in OVM by duplicating the symbol table at run-time is *really* expensive and I question if the benefits are worth the cost — especially since VMM is able to provide similar benefits without it. For better or for worse, the industry is using SV. So we designed VMM to work well with its underlying capabilities and leveraging its well-known use models with the least number of classes and macros.

Cheers.

Corey made several good points and I would like to further elaborate on the reasoning and the value for not recommending callbacks in the OVM (both e and SV).
Reusability and extensibility are very interesting topics and indeed using callbacks provides a solution for some types of extensions.

Issues with Callbacks:
———————-

There are a few key deficiencies of callbacks that your analysis overlooks.
a. Callbacks are focused on procedural extensions and do not solve the entire extensibility problem. Many times a user wants to add more fields, coverage points and events to a pre-defined verification IP. Callbacks do not address this issue.

b. The VIP developer must predict, in advance, the extension points and provide the extensions there. For example, I can develop a BFM for an AHB component following the protocol and assuming arbitration. Some systems that have only one master may decide to remove or modify the arbitration logic. If I predicted this scenario in advance, I can create callbacks around the pieces of logic that need to be extended. But the extension options are endless. Should we recommend a callback prior to every task and function in the system?

c. What about overriding/removing code? For example, I would like to mute the arbitration logic. Callbacks can be used to extend but more logic is needed for disabling pre-defined logic.

d. What about ease-of-use? You list some SW design patterns. These were introduced 15 years ago and are still relevant however there is some criticism on the complexity and encrypted style of some of these patterns. OOPSLA is an annual conference covering topics on object-oriented programming systems, languages and applications. Among their claims is instead of inventing or capturing complex patterns for solving problems, why couldn’t we create better tools/languages. Click this link to read more: http://www.sigplan.org/oopsla/oopsla99/2_ap/tech/2d1a_gang.html

Now let’s see what other solutions are there for the reuse and extensibility.

AOP and e:
———-

e did exactly what OOPSLA experts recommend – define a solution for the problem. The Aspect oriented e extend capability is a hot thing in SW languages today (read more on aspect java)

a. Fewer lines of code to create and maintain. As was mentioned so many times before before, less code equals better productivity, right?

b. Extensibility of existing class is much easier to learn/teach than design patterns

c. Supports procedural as well as structural extensions

d. No need to predict, in advance, extension points.

e. Can disable code using empty extension.

OVM SV solution:
—————-

Factory
——-

As was mentioned OVM supports callbacks. However, for extensions we recommend the factory mechanism. Why?

a. Supports procedural as well as structural extensions

b. No need to predict, in advance, extension points. Every function and task is a potential extension point.

c. Can disable code using an empty extension.

d. It is not as short and concise as e and AOP, but less lines of code than callbacks.

e. Structural extensions are easier to understand and debug.

f. As you claim in your VMM book, you need a factory anyway for data item extensions, so it is better to learn one powerful pattern than a few point solutions.

g. Most environment reuse starts the same way: A user gets a VIP component and configures/extends/instantiates it according to the local project requirements. As OVM recommends, this is done inside a set of testbench classes, one for each configuration. A family of tests is written using one of the configured testbenches. This leads people to a tree-like topology reuse.

TLM
—-

What if a graph reuse topology is needed (multiple parallel development of the same classes that later need to be combined)?

Analysis TLM ports can provide procedural extensions. Every object is passed by reference to the TLM and you can manipulate it in various environments that can later be combined.

Why TLM?

TLM analysis ports are already in place for other reasons. They can cross language boundaries, they already standardized in OSCI SystemC. Why invent, teach, and ask users to implement a new or additional solution? I heard from quite a few users that they do not know when to use VMM channels or call backs.

To summarise, use the OVM factory for all it’s benefits. If there is a real concern of orthogonal reuse, use TLM analysis ports.

Thanks and regards,

– Sharon (Cadence Design Systems)

Your posting on this topic was very informative and thorough. SystemVerilog is indeed an OOP language and, as such, has it’s limitations when it comes to easily modelling many kinds of functionality needed for performing common verification tasks. Callbacks fall nicely into that category, which is the very reason that VMM is of help here. While OOP raises the level of abstraction beyond what basic Verilog offers, there is a clear need for even further abstraction. This is confirmed by the various verification class libraries such as VMM and OVM that bring further ease-of-use to the complex challenge.

As you may be aware, Aspect Oriented Programming (AOP) languages raise the level of abstraction even further beyond what class libraries can offer as most of the library features are built right into the languages themself (as well as tons of other ease-of-use features), allowing users to build verification environments in creative ways unimaginable by most skilled OOP verification engineers, and indeed most skilled OOP SW programmers!

If I use your example of callbacks mentioned above, an AOP implementation of this feature (using the e language) would be:

unit my_xactor;
…
retrieve_forever() is {
…
while (TRUE) {
…
in_chan.get(in_tr); // Get input transaction
do_after_get(); // Call to empty method in this base unit
… // Execute transaction
do_before_put(); // Call to empty method in this base unit
out_chan.put(out_tr); // Generate output transaction
…
};
do_after_get() is empty; // define empty method to be extended later
do_before_put() is empty; // define empty method to be extended later
};
};

At first glance, the code looks quite similar to your example however, notice that there is no need to define a callback class and instantiate it within the xactor (this reduces code by removing the need to instantiate it, build it in the new() function of both the xactor and the testcase and also removes the need to append it.) Note also that there is no need to pass in any variable to the function call in the above code as all variables within the unit are visible to the function and can be accessed. I am not sure if that is the case for your example above.

Now, the beauty of AOP comes in the re-use. Since the functions are empty, they can be extended in any way desireable to implement the desired behaviour through extensions that can be based on any enumerated/boolean field of the unit/class itself. For example, if I wanted to implement specific functionality for only the BLUE xactors (where BLUE was some enumerated field differentiating this xactor from others):

extend BLUE my_xactor {
do_after_get() is also {print in_tr.item;};
do_before_put() is also { print out_tr.item;};
};

All my_xactor’s in the environment that are BLUE will now contain the above functionality. If I wanted to layer additional functionality to only the TENG ATM xactors:

extend TENG ATM my_xactor {
do_after_get() is also {out(“TENG ATM xactor input trans payload size: “,in_trans.item.payload.size()};
do_before_put() is also {out(“TENG ATM xactor output trans payload size: “,out_tr.item.payload.size();};
};

In the above situation, all TENG ATM xactors would automatically pick up the extension and the BLUE TENG ATM xactors would pick up the previous extension as well. Essentially, this is like plug and play with your callbacks, customizing each type of xactor to have the specific callback that they need automatically when the xactor is generated. Using the built in generation of the e language, these extensions would allow a user to automatically create a random list of my_xactors, each having their own unique functionality based on the random values generated for each of their internal fields. The below code is all that would be needed to achieve this.

unit my_env {
drivers: list of my_xactor is instance; //no need for build(), new() or randomize()
};

I hope you can see how the above example greatly reduces the amount of code required for callback implementation while, at the same time, allowing for much greater flexibility and functionality to be added. There is no need for extra instantiations, calls to new(), “poking” different flavours of callbacks into the environment or creating extra objects for each “flavour”. In addition, there is no need to do large scale pre-planning to determine exactly which tasks will be made virtual such that we can override their functionality later.

In my opinion, AOP is to OOP what OOP is to Verilog … a huge productivity boost. The e language was developed back in 1992 with AOP in mind and has been in use for many years however, I would be very interested in hearing your thoughts on AOP and any comments you might have on whether Synopsys is planning on pushing for AOP to be implemented in SystemVerilog, or whether VCS will be supporting any other AOP languages, such as e, anytime soon.

Again, thanks for the great detailed post.

regards,
Corey