Jump to content
sri.cvcblr

uvm_cmdline_processor - why its methods are non-virtual?

Recommended Posts

Hello,

  Recently a customer wanted a tweak to the way +UVM_* arguments are processed. Without going into details (not all are with me yet, am still asking them why they need it at first place), I could have achieved (at least I believe so) what the customer wanted by deriving my own cmd-line-processor class and overriding method like:

 

 function int get_arg_values (string match, ref string values[$]);
 
But I notice that this is non-virtual (and so are many other methods in there). Is there a good reason? If not, would the UVM 1.2 team consider making them virtual?
 
Also on a side note, the file uvm_cmdline_processor.svh doesn't use "extern" functions - maybe we should? Atleast for those lengthy ones? 
 
Thanks
Srini
 

Share this post


Link to post
Share on other sites

Srini-

 

Overriding the meaning of the +UVM_* command line options would be dangerous, as the intent is to handle them in a very specific manor. For example, if the user decided that +UVM_TESTNAME was going to be a comma separated list of values, then their code would not export to "pure UVM" environments.

 

Is there a reason why testbench and/or company-specific plusargs couldn't be used, or why you'd want to prevent the standard application of the command line switches from occurring?

 

-Justin

Share this post


Link to post
Share on other sites

For a more primitive, but related question from a novice user, see: http://forums.accellera.org/topic/1938-extending-uvm-cmdline-processor-problem/

I think I am looking for (some of) those functions to be virtual as well.

I imagine I am not the only other one working on 'enhancing' or augmenting cmdline_processor features.  Perhaps we can form a wishlist and suggest it for UVM 1.2.

Share this post


Link to post
Share on other sites

Srini-

 

Overriding the meaning of the +UVM_* command line options would be dangerous, as the intent is to handle them in a very specific manor. For example, if the user decided that +UVM_TESTNAME was going to be a comma separated list of values, then their code would not export to "pure UVM" environments.

 

Is there a reason why testbench and/or company-specific plusargs couldn't be used, or why you'd want to prevent the standard application of the command line switches from occurring?

 

-Justin

Justin,

  Ultimately it is the end-user who should decide with due diligence/guidance from the developers. In this specific case I too am asking them why they can't do it differently in their use model. Standard reply is "they can't change existing scripts/PERL/Makefiles/flows", though I didn't hear it (yet) in this case. It is surprising folks want to tweak UVM base than their scripts, but then users are users.

 

But from OOP/Methodology view, what's the reason to make them "non-virtual" if any. As Linc also points out, there can be other use cases. In VMM I recall we recommend many methods to be virtual by default.

 

Thanks

Srini

Share this post


Link to post
Share on other sites

hi,

 

>But from OOP/Methodology view, what's the reason to make them "non-virtual" if any.

 

There can be arguments for methods not being virtual (for instance different argument signature) but I agree the obvious choice for a base class library should be "virtual". other issues visible in UVM along the same lines are

 

1 member fields being non-local thus allowing access via non-function RW. that makes the field part of the API but its not something you can really override

 

2  excessive use of static class memeber references. every call to "someclass::somefct()" just ensures it will ever be that "someclass" types "somefct" member function you invoke. there is no way to override it without adding code into someclass::somefct. especially "assumed" singletons in UVM assume that it will be always a singleton of the given type. a overridden singleton instance has not been considered.

 

3 most UVM core classes are very tightly coupled due to #1+#2 making it hard/impossible to replace/override them non-intrusively

 

4 another problem here is the whole "boot" of UVM with the (undeterminate order) due to parallel static initialization. This makes it hard do perform any overrides to core functionality BEFORE something happens in UVM.

 

 

BTW a general assumption when creating OVM/UVM was that

 

#A it will provide everything you ever need and there will be no need to extend/override the core classes

#B all necessary functionality is ALREADY in the base class itself

#C preventing user from messing with the library is a good thing

#C the standard has to provide an implementation for every possible use model

 

I dont think these are good assumptions for UVM

 

 

/uwe

Share this post


Link to post
Share on other sites

We need to be careful about identifying the difference between definitions in the standard, and the implementation of the standard.  I'll use +UVM_TESTNAME as my example again:

Variable: +UVM_TESTNAME

~+UVM_TESTNAME=<class name>~ allows the user to specify which uvm_test (or
uvm_component) should be created via the factory and cycled through the UVM phases.
If multiple of these settings are provided, the first occurrence is used and a warning
is issued for subsequent settings.  For example:

<sim command> +UVM_TESTNAME=read_modify_write_test

The standard clearly defines what +UVM_TESTNAME means, and how it is to be used by the library.  It does ~not~ clearly define how that mechanism is implemented.  The reference implementation calls get_arg_values("+UVM_TESTNAME", test_names), but it could just as easily have used $test$plusargs.  The same is true for +UVM_VERBOSITY, +uvm_set_verbosity, +uvm_set_severity, etc. 

 

If the standard definitions are game for editting, then we really defeat the purpose of having a standard. 

 

That being said, the standard should provide the ability to affect the defined implementation.  The definitions should be open enough to allow for user interpretation without necessarily binding their hands. Can you provide the exact functionality which you're trying to accomplish, but can not with the current implementation?  I.e. Is the problem that you can't override get_arg_values(), or that UVM is interpretting one of the plusargs in a way which you would like to change?

Share this post


Link to post
Share on other sites

Justin,

  Thanks for the pointer to the spec for the UVM_TESTNAME part. It does make the case stronger to separate spec from implementation. I believe my question is larger in context - why am I blocked from overriding cmd_line_processor::get_arg_values() ?

 

Making them virtual is useful as a base class library is MHO (My Humble Opinion)

 

Regards

Srini

Share this post


Link to post
Share on other sites

Srini-

 

Here we get into a bit of an academic debate.  Code should be written in such a way as to maximize its ability to be reused, however standards exist in an attempt to lock down the usage model.  The more the standard allows for changing functionality, the less of a standard it becomes.  Mr. Chicken meets Mr. Egg.

 

In the case of the command line processor, the standard appears to be dancing around the fact that it wants to lock down a usage model, but then backs out at the last moment:

This class provides an interface to the command line arguments that were provided for the given simulation.  The class is intended to be used as a singleton, but that isn’t required.  The generation of the data structures which hold the command line argument information happens during construction of the class object.  A global variable called uvm_cmdline_proc is created at initialization time and may be used to access command line information.

The uvm_cmdline_processor class also provides support for setting various UVM variables from the command line such as components’ verbosities and configuration settings for integral types and strings.  Each of these capablities is described in the Built-in UVM Aware Command Line Arguments section.

If the class were _actually_ a singleton, then I would argue that the methods should be non-virtual (heck, they could even be static), but if the class is _NOT_ a singleton, then your request makes sense.  

 

Perhaps what we really need is to support both models?

 

I'd like to open up a Mantis item on this, but want to make sure I properly encapsulate your request.  Would it be sufficient to request:

 

A- UVM provide a mechanism for raw (unfiltered) access to the command line arguments, essentially what we have now

B- UVM provide a mechanism for filtered access to the command line arguments, via extension of the command line processor

C- UVM provide a mechanism for setting a 'default' cmdline processor (similar to factory, report_server, etc)

 

?

Share this post


Link to post
Share on other sites

Hello,

  Thanks for listening and Mantis help (as part of Accellera Member company I hoe you can open a Mantis ticket if needed here). From my reading of your options above, the "C" (i.e. provide a default setting one - assuming that would allow user to override the methods at will - putting the end user on top, but be responsible and accountable on what he/she overrides - including the risk of non-standard use model) would be good fit. 

 

On the singleton topic - IIRC currently the function cmd_line_processor::new is NOT protected, so if it indeed is intended to be singleton, maybe we should fix that as well (though that would complicate the use case for this customer even more).

 

Regards

Srini

Share this post


Link to post
Share on other sites

Sorry, I should have been more clear:  I was suggesting A, B ~AND~ C, not A or B or C :)

 

So there would be a mechanism to get raw unfiltered access for those who want it.  There would ~also~ be a way to extend the command line processor and provide filtered access.  Since we're talking about extending the command line processor, that means we're potentially going to have multiple command line processors.  If we have more than one, then we should be providing a mechanism to set/get the default.

 

You're absolutely right about the new() method, it isn't protected, which means you can create your own command line processor, but there's a very limited set of reasons to do that when all of the get_* methods are non-virtual :-p

 

I can definitely open a Mantis on behalf of this topic, I'm just trying to nail down the requirements.

Share this post


Link to post
Share on other sites

Sorry, I should have been more clear:  I was suggesting A, B ~AND~ C, not A or B or C :)

 

 

 

Wonderful, thanks :-) 

 

 

jrefice

[sNIP]

 

You're absolutely right about the new() method, it isn't protected, which means you can create your own command line processor, but there's a very limited set of reasons to do that when all of the get_* methods are non-virtual :-p  

 
 

That was precisely my point about this thread! The new() is non-protected, and the methods are non-virtual...

 

Thanks again

Srini

 

Share this post


Link to post
Share on other sites

Ankit,

  Plain Verilog $value$plusargs seems the easiest, a UVM flavor of it if you will could be:

 

   void'(uvm_cmdline_proc.get_arg_value("+field_val1=",seq_field_val_as_str));
    seq_val_int = seq_field_val_as_str.atoi();
    `uvm_info ("CVC", $sformatf ("String Value from cmd line is: %0s Int value is: %0d",
                                
                                 seq_field_val_as_str, seq_val_int), UVM_MEDIUM)

Share this post


Link to post
Share on other sites

BTW, please start this as a separate thread as it seems unrelated to some extent. And if you were thinking of using built-in +uvm_set_config_int approach, recall it is meant for components only and not for SEQ.

 

Good Luck

Srini

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×