The goal of modern verification techniques is to do as much as possible with as little code as possible. This is best done with a "write once, tweak everywhere" approach to test development. This type of flexibility comes for free in AOP; that's why it's built into e's DNA. For OOP, however, it requires thought and planning, and is achieved by using design patterns. One reason why the UVM exists is to encapsulate some of these patterns for us (especially the factory). Even so, this doesn't mean that some design pattern knowledge won't help us do fancy stuff in our code.
Thanks for this wonderful blog showing us how to use multiple inheritance in verification.
I have one question which method is better to use
Put all the constraint in one sequence item and then use constraint mode function to enable and disable the constraint depending upon our scenario.
or to use multiple inheritance method as shown in your blog. i felt sometimes Multiple inheritance can create some confusion and might make difficult in debugging .
Also please let me know if there is some more applications of multiple inheritance in verification.
T is going to be given a value the moment you parameterize the mixin (i.e. apply it on a class). T can be of any type as long as this type contains fields referenced by the mixin. For example, the corner_case_mixin references mode, privilege, etc. It can therefore work with vgm_ahb_item and any of its subclasses.
I intentionally left T without a default value to have the user explicitly choose one.
I’d say that having all of the constraints in one big class would lead to maintenance hell. You’re going to need to disable/enable the constraints every time and that’s going to mean a lot of procedural code. I don’t think “multiple inheritance” is more difficult to debug (seeing as how we implement it here it’s anyway using single inheritance). The inheritance tree is maybe a bit more complicated, but you can’t get something for nothing.
As to where else this is applicable, I can’t really say for sure. I remember having strained my brain in coming up with a scenario where this is useful. I found the implementation of TLM ports is a good example. As to other uses, we’ll just have to wait and see.
thank you very much!!! I really appreciate this idea of using a “mixin” to manage the sequence_item constraints for sequences.
Have you had any tweaks or realizations on method since you posted this? I would like to start implementing this, but am weary of doing something too “foreign” to others and creating a methodology shift if it has some other drawbacks. So, do you have any further info since?
Again, thanks! We all need to get more practical sw training as verification engineers.
I have one small tweak. I define mixins as abstract classes and, in the context of UVM classes, don’t do any kind of factory registration stuff in there (it anyway doesn’t work for ‘virtual’ classes: