Jump to content

sri.cvcblr

Members
  • Content Count

    46
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by sri.cvcblr

  1. 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
  2. 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
  3. Impressed! Well done! Thanks for sharing the code. Regards Srini
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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)
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. Version 2014.02

    379 downloads

    Fixed few enum type-cast issues. Moved around the file ordering as needed by compilers. Added extra target for Riviera-Pro Fixed few issues in reg_models. Added Makefile targets for all 3 major EDA tools Steps to use ----------- tar xvfz uvm_ref_flow_2014.02.tgz cd run_dir make vcs make qsta make cdn make rvra
  23. Strange, could be temporary server issue, retry please. We are updating this flow adding another EDA tool script support (Riviera-PRO from Aldec), so expect an update soon. In case you need it urgently, drop us a note via www.cvcblr.com Srini
  24. QUick note: See: http://forums.accellera.org/files/file/99-uvm-ref-flow-soc-kit-originally-from-cadence-modified-to-work-with-vcs-questa-ius/ It contains Makefile to run on all 3 major tools and fixes needed to do so. Tested with IUS 12.2 VCS 2012.09 Questa 10.2 Srini www.cvcblr.com/blog
  25. Version 2014.02

    921 downloads

    Fixed few enum type-cast issues. Moved around the file ordering as needed by compilers. Added extra target for Riviera-Pro Fixed few issues in reg_models. Added Makefile targets for all 3 major EDA tools Steps to use ----------- tar xvfz uvm_ref_flow_2014.02.tgz cd run_dir make vcs make qsta make cdn make rvra
×
×
  • Create New...