Difference between pre callback and post callback

Can anyone explain in detail pre callback and post callback. What feature we define in both of them?

Please I need it urgently … Am having confusion abt it

In reply to pmehro:

There are many different kinds of callbacks in UVM for very advanced usage. We normally recommend against using them. We prefer that you use the Object-Oriented virtual method extension mechanism to add functionality. Can you explain where in particular you are seeing the need to use callbacks?

1 Like

In reply to dave_59:

Actually this question was asked to me in Interview. And I went through callback chapter in SYSTEMVERILOG FOR VERIFICATION A Guide to Learning the Testbench Language Features Page no 236 they mentioned of post and pre callback mechanism I could not understand where to use them…

In reply to pmehro:

In that case, there is nothing special about pre- and post- callbacks. It simply is a place to add functionality before and after a particular statement.

1 Like

Thanks for info. Can you please provide some sample code and some scenario where we can use it.

In reply to pmehro:

I don’t recommend using them, so no example. Instead, I recommend using the standard OO principal of inheritance and virtual methods.

class A;
virtual task Transmit;
// stuff to transmit
endtask
endclass

class Aext extends A;

virtual task Transmit;
// statements that would have been in the pre_ callback go here
if (some_expression)
   super.Transmit() // call the base method, or not
// statements that would have been in the post_ callback go here
endtask
endclass

Hi @dave_59,

Could you please elaborate why you don’t recommend using callbacks?
In which cases it behaves odd? Or breaks functionality?

Thanks,
Michael

1 Like

After all these years, I’ve come to soften my recommendation. Each style has its pros and cons. I would also suggest a third option: the decorator pattern.

1. Callbacks

Usage: Typically implemented using interfaces with virtual methods or class handles passed as arguments to inject behavior.

:white_check_mark: Pros:

  • Flexible behavior injection: You can swap out implementations without modifying the generator logic.
  • Promotes decoupling: Useful in testbenches where stimulus and response are separated.

:cross_mark: Cons:

  • Harder to trace: Debugging callback chains can be tricky, especially when multiple layers are involved.
  • Runtime Overhead: If callbacks aren’t used, you still pay a performance penalty.

2. Virtual Methods

Usage: Core to polymorphism in SystemVerilog; allows base classes to define behavior that derived classes override.

:white_check_mark: Pros:

  • Polymorphism: Enables dynamic behavior based on object type.
  • Extensibility: Easy to add new behaviors via subclassing.

:cross_mark: Cons:

  • Inheritance rigidity: Deep hierarchies can become hard to manage.

3. Decorator Pattern

Usage: Less common but achievable by wrapping objects and forwarding calls. Useful for layering functionality.

:white_check_mark: Pros:

  • Behavior layering: Add features without modifying original class.
  • Avoids subclass explosion: Compose behaviors instead of creating many subclasses.

:cross_mark: Cons:

  • Complex object chains: Multiple decorators can make debugging harder.
  • Manual forwarding: You must explicitly forward all methods, which can be tedious.

Thanks for the response @dave_59,

The link to the “decorator pattern” seems to be broken..

I’ve corrected the error. I missed one character when copy&pasting.