unknown_ifb Imported from Blogger

Hi Tudor

what should be “T” in this
class corner_case_mixin #(type T) extends T; ??

my guess: uvm_sequence_item

M I correct?

1 reply

raku_ifb Imported from Blogger

Hi Tudor,

Thanks for this wonderful blog showing us how to use multiple inheritance in verification.

I have one question which method is better to use

1. Put all the constraint in one sequence item and then use constraint mode function to enable and disable the constraint depending upon our scenario.
2. 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.

Thanks

1 reply

TudorTimi Verification Gentleman

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.

TudorTimi Verification Gentleman

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.

unknown_ifb Imported from Blogger

Tudor,

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.

-peter
www.linkedin.com/in/asicdvpete

1 reply

TudorTimi Verification Gentleman

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:

virtual class some_mixin #(type T) extends T;
// … constraints
// … constructor
endclass

This forces users to declare a new class to layer the required mixins. The advantage is that you end up with reasonable type names:

class some_class extends some_mixin #(some_base_class);
`uvm_object_utils(some_class)
endclass

nimw

Doesn’t this limit us to only being able to stack 2 constraints?

Have you read “SystemVerilog Constraint Layering via Reusable Randomization Policy Classes” by John Dickol?

1 reply

TudorTimi Verification Gentleman

I doesn’t limit, but it’s kind of awkward to use.

In the meantime, I settled on this: Favor Composition Over Inheritance - Even for Constraints | Verification Gentleman Blog. There’s a section there which talks about why I don’t use mixins for constraints anymore.

nimw

Oh right, you can use as many # as you’d like.

About the link you provided, the link to the paper : http://events.dvcon.org/2015/proceedings/papers/04P_11.pdf

doesn’t work for me. Do you have it saved? If so, can you please upload it?

Another question - Is the theoretic or do you actually use this pattern in your day to day?

1 reply

TudorTimi Verification Gentleman

That was a link to the paper you mentioned. They moved the proceedings to SystemVerilog Constraint Layering via Reusable Randomization Policy Classes – DVCon Proceedings Archive. I’ll update the link.

We built a lot of infrastructure around constraint objects, global constraints and dynamic test creation, as outlined in Creating UVM Tests Dynamically | Verification Gentleman Blog, which we use productively.