This week I stumbled on an issue with the UVM base class library (BCL). I was using the register layer to access some memories and some things just didn't add up. I've posted a description in the forums, so let's see what the higher ups say.
But, but, but… If there is any existing code that extends the UVM base class that you’ve patched and factory-overridden, you’re opening the gates to a world of hurt with class type incompatibility thanks to your branched class hierarchy. This is the same problem that afflicts any attempt to make site-specific extensions of the normal UVM component or object base classes.
Of course you’re correct to point out that AOP could solve this. But the real blame lies not with lack of AOP, but with your vendor who has allowed a flawed base class to infiltrate their non-patchable BCL distribution.
I don’t recall who it was that first said “prefer composition over inheritance”, but they were right.
I didn’t really think about that (I was too focused on uvm_reg_map and, seriously, who’s going to extend that?). In that case, you’d need to extend from the patch class instead of the original class => more intrusiveness.
The Gang of Four said “prefer composition over inheritance” in their “Design Patterns” book.
When the buggy code in the BCL is sealed up in class that hasn’t been registered with the factory, with no virtual methods and/or the class properties (variables) you need to reach are local, you can download the reference library then fix it yourself. Then you bypass the simulator’s pre-compiled versions of the library and compile your own version instead. I always do this anyway because I have to pass in some defines from the command-line that alters the default behavior of the BCL. The pre-compiled binaries are useless to me.
Of course, you will lose your fixes with the next release of UVM, but 1.2 is solid and should be around for quite a while. Back when I did this for OVM when it was changing from time to time, I just had to run a diff and patch the new release myself.
hi,
this is a hot topic. unfortunately the BCL is so monolithic and has too much non-virtuals, visible member fields, static by-type access etc so that non-intrusive changes are almost impossible. Doing more GOF would make sense but likely require a rewrite of UVM and more SW/OO patterns would leave those behind who are already asking for an “easier uvm”.
I’d be in favor of a gradual rewrite (and also a split, but more on that in some future post). UVM is anyway supposed to be a library, so how it does its stuff should be transparent to the users. It can use as many patterns in the background as it likes.
I just wanted to comment to congratulate you on reading Refactoring. Awesome book. I wish more verification engineers would read it.
I didn’t read it yet. It’s in the works. I plan to do a post on it.