UVM's community process could use some upgrades

Overall, UVM is a net benefit to my job. Having a standard base class library makes it easier to create reusable test benches quickly. The API has been submitted to the IEEE for standardization, which should encourage even more use in the ASIC industry. However, the development of the reference implementation is woefully mis-managed.

Let's take a look at some of my favorite issues in the Accellera Mantis database for UVM:

• uvm_reg_map::clone doesnt clone, doesnt emit a message and silently returns NULL

  This one is pretty self descriptive. Being able to clone a register map would be extremely useful when several physical ports all share the same set of registers - the default map could be cloned and associated with a port. However, as the summary for this issue says, clone() does not work. Why does it not work? Well, here's the text of the method, as currently implemented:

  function uvm_object uvm_reg_map::clone();
      //uvm_rap_map me;
      //me = new this;
      //return me;
      return null;
  endfunction
  

  No further comment necessary.

• uvm_heartbeat does not respect the comps list

  This one is a bit more esoteric, but it has been an issue for me when trying to use the uvm_heartbeat class. Helpfully, the reporter also attached a proposed fix, but it does not appear the fix has been accepted. The reporter's name has been struck out (perhaps the account is no longer active?) and the issue labeled 'errata'. I do not think that is the appropriate classification for an issue like this.

Now, I am definitely not the first one to notice how buggy the reference implementation is. The topic first came to my attention when I saw a talk at SNUG 2014. The paper itself is behind a Synopsys login (of course), but a summary of the concerns is available. The authors have done a great job of creating a project to unit-test the UVM library, but that's only half the battle. If bugs are discovered and reported, someone still has to fix them, and as the bugs above show, that's just not happening.

In a better world, the UVM reference implementation would be run more like most open source projects, where pull requests to fix issues could be submitted and reviewed in a timely manner. These fixes would be aggregated in smaller point releases more often, with something like UVM-UTest giving users confidence that regressions will be caught. In the meantime, fixes for long-standing bugs are only available by manually patching your local copy of the framework, which is obviously not ideal.

I understand that maintaining a large, complicated framework like this is hard, and I am not claiming I could do better. I am suggesting that adopting proven methods for managing an open framework like this could reap huge benefits.

Anyone else have some hilarious (or sad) bugs that have lived on for too long?