Jump to content

UVM_ALL_ON -vs- UVM_DEFAULT


Recommended Posts

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.

Link to comment
Share on other sites

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 by dave_59
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...