• Content count

  • Joined

  • Last visited

About jrefice

  • Rank

Profile Information

  • Gender
    Not Telling
  1. This is a catch-22 in the library. There's no guarantee that finish_item() actually indicates that the driver has completed processing the item, and there's no guarantee that the driver is going to trigger the appropriate events. Ideally, if the driver detects that seq_item_port.is_auto_item_recording_enabled() returns '0', then the driver should manually call accept/begin/end_tr. These calls will cause the appropriate events to trigger inside of the item.
  2. Martin- I've opened two mantis items for your requests. http://www.eda.org/mantis/view.php?id=4998 http://www.eda.org/mantis/view.php?id=4997 Thanks!
  3. I've opened up a Mantis for your request, thanks! http://www.eda.org/mantis/view.php?id=4996
  4. Bart- That's definitely a bug in the library, and there's a mantis item open for it at: http://www.eda.org/mantis/view.php?id=4969 For the record, "get_starting_phase()" isn't 'optional', it's the official mechanism for retrieving the starting phase. The old "starting_phase" variable is considered deprecated in UVM 1.2... so if there are no references to it whatsoever, then everything works. The bug is in the deprecation code, which isn't properly setting the old variable. Thanks for the help, -Justin
  5. 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.
  6. The UVM resources facility is extremely powerful, however it's hamstrung by the fact that resources are strictly tied to the resource pool. This prevents them from being a generalized solution, and forces them into a very specific usage model which is riddled with performance concerns. Looking at the resource classes: uvm_resource_base: precedence default_precedence set_scope get_scope *match_scope *set_priority uvm_resource#(T): set set_override *get_by_name *get_by_type *set_priority *get_highest_precedence All of those methods and fields are strictly bound to the resource pool, and the '*' methods are just helpers which redirect to resource pool methods. If resources had no knowledge of the pool, then they become a simple storage structure which can be used as a basis for TLM GP Extensions, Report Message Elements, Configuration, etc., instead of the disparate solutions that the standard presents right now.
  7. 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) ?
  8. 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?
  9. Just bringing together some disparate threads comments here... The tar.gz does contain an HTML version of the reference guide, and it can be browsed after downloading. There is presently no Accellera "Hosted" copy of the HTML docs, such that you could go to www.accellera.org/.../uvm-1.1d/docs/html/index.html and browse. As for the User's guide, it is now being treated separately from the base class library, and the release notes should not have mentioned it at all. The Accellera WG is currently working on the User's Guide for 1.2, so keep an eye on the forums for an update!
  10. 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
  11. Version


    Since the release of the UVM 1.0, one of the least documented features of the methodology has been the Run-Time Phasing solution. Due to this lack of documentation, many users were immediately turned off from trying to use this new area of the methodology. Even more unfortunate were those users who were brave enough to try and blaze the trail, but were quickly mired down in misuse, misinterpretation, and a general lack of support. This lack of documentation, combined with a general misunderstanding of what Run-time phasing was intended to solve, lead to many users labeling it as “unsafe”, and “overly complicated.” This document strives to remove the veil of confusion which the UVM’s Run-time phasing is wrapped in, by clarifying its intent and showing how easy it is to build very powerful stimulus.
  12. In UVM 1.1b (and prior), the set_timeout() and `UVM_DEFAULT_TIMEOUT method were rather vaguely documented (and in the case of set_timeout, the default mentioned was wrong): As Peter said, this doesn't state what happens when a timeout is hit, simply that the timeout exists. This lead to users trying to use the timeout to control individual phases, which was not the intent of this particular mechanism. Add to that the fact that the implementation of timeout in 1.1b was inconsistent, and did not actually do what the reference guide described, and now you've got the makings for Mantis 4295 (which changed this area of the code). The new documentation is much clearer: The user can still create a timeout of their own, which can produce an error/warning/etc. and then end the simulation in whichever way they want, but this mechanism was intended to be "the big red button". If we hit it, then something in the phasing graph is hung, although we don't necessarily know what. We dump out immediately, showing which phase objections are active, and do not attempt to proceed any further in the phasing graph.