cliffc Posted December 12, 2012 Report Share Posted December 12, 2012 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. Quote Link to comment Share on other sites More sharing options...
KathleenMeade Posted December 13, 2012 Report Share Posted December 13, 2012 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 1 Quote Link to comment Share on other sites More sharing options...
cliffc Posted December 13, 2012 Author Report Share Posted December 13, 2012 Hi, Kathleen - Interesting perspective. Thanks for the reply. I wonder if anybody has a different opinion. Regards - Cliff Cummings Sunburst Design, Inc. Quote Link to comment Share on other sites More sharing options...
dave_59 Posted December 13, 2012 Report Share Posted December 13, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
cliffc Posted December 13, 2012 Author Report Share Posted December 13, 2012 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 Quote Link to comment Share on other sites More sharing options...
dave_59 Posted December 13, 2012 Report Share Posted December 13, 2012 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 Quote Link to comment Share on other sites More sharing options...
ajeetha.cvc Posted December 13, 2012 Report Share Posted December 13, 2012 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 cliffc 1 Quote Link to comment Share on other sites More sharing options...
bhunter1972 Posted December 13, 2012 Report Share Posted December 13, 2012 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. cliffc 1 Quote Link to comment Share on other sites More sharing options...
dave_59 Posted December 13, 2012 Report Share Posted December 13, 2012 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. Quote Link to comment Share on other sites More sharing options...
petermonsson Posted December 13, 2012 Report Share Posted December 13, 2012 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 Quote Link to comment Share on other sites More sharing options...
bhunter1972 Posted December 13, 2012 Report Share Posted December 13, 2012 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 cliffc 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.