UVM: Improvements

What are the things which you would like to improve upon on UVM?

In reply to sharatk:

I believe your question is quite useless, because you can make a big list of things to added to the UVM but nobody does need them. Improvements should be always considered with respect to to certain functionalities or applications.
Please specify your question.

In reply to sharatk:

This is a great question. It’s also a good one for the SystemVerilog standard. The best improvement for both of them is making them even more stable by fixing all their bugs. The big problem with design by committee is that you can always get new energy from people to add in new features, but it’s much more difficult to get the same kind of energy to fix bugs.

And then there’s the issue of how one defines a bug. That’s easy when a feature is completely unusable (see recent discussions of
uvm_reg_fifo
, but crosses the line into an enhancement when its missing a key feature to make it completely usable. (see discussions on
umm_reg_map

Since the UVM is now just an IEEE document like the SystemVerilog standard, not actual code, my personal opinion is working on improving the standard to make sure it captures the intent of all features correctly the way people want it implemented.

Thanks Dave. Great point.

I think that debugging can be made a little easier. For example consider the below code. Dont look at coding guidelines or semantics here.

fork
forever begin
poll_register_sequence();
end
#10ms.//Timeout
join_any
disable fork;
other_seq.start(env.seqr);

So, Killing a sequence mid-flight jammed my sequencer and it took me a better part of the day to understand what was happening. UVM gave me no error/warning to help me traige the issue. I think these can be made better.

In reply to sharatk:

Well, the UVM Cookbook does tell you to never stop a sequence…

In reply to cgales:

It does of course. All I am saying is an Error message would have made traige easy.
Consider a typical SOC when there are 100s of other threads going. Somebody locking the sequencer kills the test for everybody else. For that bloke’s block it might have worked since he ends his test after this, but when ported over, it would be a debug nightmare and partly because UVM does not point it out.

In reply to sharatk:

Unfortunately, no matter how much effort is used to try and predict the varying error conditions, someone will come along and do something completely unexpected.

Hi Dave,

In reply to dave_59:
Since the UVM is now just an IEEE document like the SystemVerilog standard, not actual code[/quote]

I didn’t realize this. Is there still an Accellera committee that’s maintaining the reference implementation and user guide, or has that been disbanded?

In reply to warnerrs:

Yes, there is still an Accellera committee that maintains the reference implementation. But since they are made up of the same people, usually one of them is dormant while the other is active. Ideally the code and the documentation should be in sync, but that’s not always the case.