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

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

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

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