sri.cvcblr

Is there any update on this comparator class? Is it still considered bad/old/inflexible and let users write their own using tlm_analysis_fifo? Thanks Srini

I see uvm_sequencer_base::wait_for_grant (UVM 1.1d) is a virtual task but accesses a local int g_request_id - is this not a bad coding style? If I were to override this virtual method for debug with much of the code intact tool throws an error for his local bar in a derived SQR class. I extended a SQR class and copied all the code for wait_for_grant and started tweaking - couldn't proceed with that debug due to this member being local. Should it be protected instead of local? Thanks Srini wwww.go2uvm.org

Impressed! Well done! Thanks for sharing the code. Regards Srini

You could use a file read task as body inside a sequence and let the regular ENV --> Agent --> SQR --> DRVR setup as-is. Yes your SQR is not really "sequencing" stuff, but an arbiter with just one req active is not as bad as it may sound! However an alternate approach is to use a Test layer alone and get rid of other unwanted pieces of UVM layers to keep it simple. This is what we have seen some users do with our opensource Go2UVM package - see www.go2uvm.org for more details on this if interested. Regards Srini www.verifworks.com

The easiest is perhaps to run a post-processing script. If you insist you want to do this within simulation domain, try: 1. Your tool may have some API to get you all $error (Assuming that error originated from a $error and not plain $display) 2. You could do a "grep -c ERROR" and another grep -c UVM_ERROR and calculate the difference and increase the count. There are some tiny little details to get there as plain old Verilog's $system won't allow return values to be easy to access within Verilog. You could always write your own C layer around, but is it really worth it? Maybe a good task for an intern if you have access to! Regards Srini www.verifworks.com

It is bad coding style and discouraged to use implication in cover property for the vacuity reason that Tudor has explained. This question often comes up and we now have it as part of our SV Quiz @ http://www.verifjobs.com We discuss this in our SVA book in the coding guidelines chapter and we are adding it as a rule to our upcoming DVRules-SVA product too! Regards Srini

Hi Cliff, VCS provides a -top option for this, however it is a compile-time as far as I remember. Give it a try and see if that helps. Regards Srini www.verifworks.com

I know I am late to respond here, but we have a new start-up named VerifWorks (http://www.verifworks.com) that targets similar thing. We do have a SV, SVA & UVM linter built on top of a Python API provided by Invionics (http://www.invonics.com), however we also have a native DVRules product that is in early Beta now that works via reflection API natively with simulator of your choice. Strictly speaking DVRules (native) is "rule checker" than a linter (as in parsing level). More details soon @ our Web site. Please do contact me offline if interested. Warm Regards Srini

I know that both VCS and Questa supports checker. Few quarters/years back even Aldec's Riviera-PRO added some basic support. For VCS there is a special flag needed to compile it though. Regards, Srini http://www.verifworks.com

You will need to do a typedef and use it, something like: typedef logic [31:0] dyn_d_t []; dyn_d_t txdata; (at both read_by_name and set sides). Then use #(dyn_d_t) Try it, if it doesn't work show us more code. HTH Srini www.cvcblr.com

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

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)

You need to use latest IUS/NCVerilog version for this, atleast IUS 13.1 version. You may also need to add specific flags, contact me offline if you need more help (srini <> cvcblr.com) Good Luck Srini

I am no C++ expert, but delete() is actually a pre-defined method name for some array types in pure SV itself. So am wondering if that would have an impact somewhere or the other during this porting journey. In anycase, this in indeed a good catch and it will help if there is a way we can screen the entire UVM base code to identify all such issues (at least as many as possible) and address them. Thanks Srini

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

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

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

For OVL one could easily add a call to `uvm_error in the std_task file. PSL - little tricky, one can use tool's TCL to do this, though it can impact some performance. An example is at: http://www.cadence.com/Community/forums/p/12847/18903.aspx Srini

Good suggestions. I would add one more option: 1. Enhance the ovm-2-uvm script to convert ovm_report_error/warning to `uvm_error - though it can be little involved at times But changing the default verbosity to NONE seems easy enough. BTW - Adam/Hillel/Thomas - assuming the UVM chairs are hearing these feedbacks, what's the process for fixing/accepting these and notifying the originators of these issues? Some of us are from non-Accellera member companies and hence won't be able to follow your internal discussions. Will there be a formal/informal communication here to summarise the changes? Also any timelines for the same please? Thanks Srini

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

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