UVM_ALL_ON -vs- UVM_DEFAULT

[cliffc]

Hi, All -

There are two field macro flags that seem to do about the same thing. I am looking for an additional insight into these two flags.

Both UVM_DEFAULT and UVM_ALL_ON seem to set all of the copy, compare, print, pack, etc. flags. Looking at the UVM source files, it seems that UVM_DEFAULT also has a depth flag set that is not included in UVM_ALL_ON, but I/m not sure what that means.

I thought I once read that UVM_DEFAULT was intended to be UVM_ALL_ON but that it would be possibly modified by the VIP committee to take on more intelligent defaults in the future, but I can't find any reference to that possibility at this time.

I also read in some of the VIP Mantis items that UVM_DEFAULT needed definition or needed to be deprecated.

Can anybody shed light on the use (or avoidance) of UVM_DEFAULT?

Regards - Cliff Cummings

Sunburst Design, Inc.

[KathleenMeade]

Hi Cliff,

My recommendation is to use UVM_DEFAULT instead of UVM_ALL_ON even though they both essentially do the same thing today. At some point the class library may add another "bit-flag" which may not necessarily be the DEFAULT. If you use UVM_ALL_ON, that would imply that whatever flag it is would be "ON".

Kathleen

[cliffc]

Hi, Kathleen -

Interesting perspective. Thanks for the reply. I wonder if anybody has a different opinion.

Regards - Cliff Cummings

Sunburst Design, Inc.

[dave_59]

Hi Cliff,

As you may know from the DVcon2011 Best Paper, there are many people who do not recommend the use of the field automation macros at all.

Dave

http://www.businesswire.com/news/home/20110308006709/en/DVCon-2011-Announces-Paper-Reports-Significant-Attendance

https://verificationacademy.com/cookbook/MacroCostBenefit

Edited December 13, 2012 by dave_59

[cliffc]

Hi, Dave -

I attended Adam Erickson's excellent and compelling presentation on this topic (paper available at http://www.mentor.com/products/fv/verificationhorizons/upload/horizons-jun-11.pdf ), but there are a number of users that prefer to use the field macros due to their ease of use, despite the performance issues, which is why I at least want to know what the best methods are for those who choose to use the field macros.

Thanks for the reply.

Regards - Cliff

[dave_59]

Hi Cliff,

I don't think they're easy to use when I see problems like this at least once a week.

https://forum.verificationacademy.com/forum/verification-methodology-discussion-forum/uvm-forum/29427-uvmconfigdbset-method-does-not-work

[ajeetha.cvc]

Hi, Dave -

I attended Adam Erickson's excellent and compelling presentation on this topic (paper available at http://www.mentor.com/products/fv/verificationhorizons/upload/horizons-jun-11.pdf ), but there are a number of users that prefer to use the field macros due to their ease of use, despite the performance issues, which is why I at least want to know what the best methods are for those who choose to use the field macros.

Thanks for the reply.

Regards - Cliff

Same here - many of our customers use these macros and often don't buy into this performance argument. Especially if they come from Specman background they got used to these stuff built-in to the language. With all due respect to AdamE's excellent paper - why can't the VIP-TSC decide one way or the other for the benefit of large user base? Having something defined with > 1000 lines of code in base class and saying don't use - doesn't seem to go well - atleast with our customers here.

On the original point/debate - interestingly we prefer ALL_ON to DEFAULT as it is more "explicit" in naming and one can make exceptions via:

ALL_ON | NO_COPY

for instance. With DEFAULT - it is possible that a newer version of UVM base code might change the definition of default, and one needs to update the code!

Any other views please?

Ajeetha, CVC

www.cvcblr.com/blog

[bhunter1972]

In my opinion, the recommendation to just never use the field macros is wrong-headed and foolish. I, too, attended Adam's presentation and found it to be compelling but not overwhelming. You should certainly know what they do and how to use them, and in this regard the existing documentation is pretty inadequate. Once you understand how to use them properly, they offer numerous advantages over the do-it-yourself approach, the most important of which is consistency. Further, the use of the macros has the benefit that as the UVM codebase improves, your code will receive those improvements, too.

But, that is a much longer thread, and may lead to some sort of jihad.

To your original question, Cliff, there is a slight difference between UVM_DEFAULT and UVM_ALL_ON. From uvm_object_globals.svh (in 1.1b and 1.1c):

//A=ABSTRACT Y=PHYSICAL

//F=REFERENCE, S=SHALLOW, D=DEEP

//K=PACK, R=RECORD, P=PRINT, M=COMPARE, C=COPY

//--------------------------- AYFSD K R P M C

parameter UVM_DEFAULT = 'b000010101010101;

parameter UVM_ALL_ON = 'b000000101010101;

So, UVM_DEFAULT turns on the "D"EEP bit, whereas UVM_ALL_ON (ironically) has it turned off.

[dave_59]

Ajeetha,

You are unwittingly helping my case. Most users are completely unaware of the 1000s of lines of code these macros invoke. Yes, the performance has improved since the OVM code base, but that is only one of many issues we see users all the time with these macros

1. Auto configuration differences between uvm_components and other classes

2. restrictions on the available field data types

3. hard coded limits placed on all integral types, and packed representations of classes that must be changed for all integral fields.

Bhunter,

I don't see the efficiency of the UVM improving anytime soon. All I see the committee is adding new features, or replacing features with re-architected features. I don't see any work to make the existing features more efficient keeping the existing API.

[petermonsson]

Hi all,

My simulator has a profile switch so I profile my code. I don't recognize the problems mentioned with macros. I have never seen a problem with their performance. I am curious. Where do you typically experience problems?

Best Regards

Peter

[bhunter1972]

Bhunter,

I don't see the efficiency of the UVM improving anytime soon. All I see the committee is adding new features, or replacing features with re-architected features. I don't see any work to make the existing features more efficient keeping the existing API.

Efficiency in terms of what? Compile time? Development time? Run time? Or debug time? You have to be specific about what you feel is wrong with the macros and then ask which is most important to you. If the only argument against is that your users misuse it because they don't understand it, then educating them properly is the correct answer.

Do the macros increase compile time? Sure, because they add code that is not always needed. But, compile-time is the cheapest of all of the above.

Do they reduce debug and development time? When used properly, yes, I find that they do.

Adam's presentation profiled OVM. From OVM to UVM he admitted there was already a performance improvement. Will there always be improvements? Hard to know.

But, his solution that you simply write the print(), copy(), and compare() functions yourself (because its just so easy?!?) greatly increases your development time and the amount of time you spend debugging the mistakes you make. We're here to find bugs that designers make, not make more of our own. The macros let you avoid all of that.

I read your answer to the forum question (https://forum.verificationacademy.com/forum/verification-methodology-discussion-forum/uvm-forum/29427-uvmconfigdbset-method-does-not-work). You avoid educating your users about the differences between components and objects and you instead just say "don't use them." That seems like the lazy approach to me.

Brian