Jump to content

jrefice

Members
  • Content count

    17
  • Joined

  • Last visited

Everything posted by jrefice

  1. It's difficult to provide more details without knowing what your environment looks like. Would you be able to provide a loose description of your environment (What sequencers and drivers exist)? Generally speaking, I'm talking about cloning the sequence (or sequence items) after the randomization has occurred, so that you have 2 independent threads operating in parallel and doing the same things on different DUTs.
  2. Would it be sufficient to clone the original sequence, and execute the clone in parallel on the TLM model's sequencer/driver?
  3. @sharvil111- This would appear to be a valid bug in the RTL, and it is now being tracked in Mantis (https://accellera.mantishub.io/view.php?id=6745). We'll post an update here when the bug is resolved, hopefully in time for the 2017 1.0 release. -Justin
  4. jrefice

    What's New in IEEE-UVM?

    Wow, starting the questions off with a (not entirely unexpected) doozy! 🙂 Unfortunately there's no single document which states "Here's a full list of everything that changed". This is because a large number of changes were performed by the Accellera UVM WG prior to the IEEE UVM WG spinning up, so there was never a single "central" location wherein everything was tracked. Many of the changes were also "non-functional", ie. the removal of user's guide-esque material and removing the accidental documentation of implementation-specific artifacts. The best list we've got of functional changes is the bug database where we tracked the changes required to convert the UVM 1.2 reference implementation to UVM 2017 0.9, and that's not really intended for mass consumption. If I were to go through that list and pick "Justin's Top-N": Accessors- Almost all fields (e.g. printer knobs, etc) have been replaced with set_/get_<field> accessors. Besides for simply being a better coding convention, this allows for greater extensibility. Opening up the core services- The user now has the ability to insert their own code within the core services of UVM. One common use case for this would be to create a factory debugger, such that all calls to the factory get reported, or a resource pool with a more performant implementation. It's even possible to implement one's own uvm_root, however that has some additional restrictions called out by the LRM. In the past all of these would have required the user to hack inside their own version of the library. Library initialization- The library no longer mandates that initialization happen during static init. It must happen during time 0, but any time during time 0 is sufficient. This allows the user to leverage #2, but it also allows for new use cases (e.g. "parameterized classes participating in the name-based factory"). There's also new hooks in the library which allow the user to "start and stop with run_test". Removing the black magic- Anyone brave enough to expand the field macros would know that pre-2017, there was some scary and completely undocumented stuff going on there. This has all been refactored, and just as importantly, documented in 1800.2-2017, such that users can now implement their own macros and/or policies without having to worry about how it would interact with the Accellera library's implementation. Policy changes- Lots of extensibility changes here. Printer, packer, et. al now derive from a single common source (uvm_policy). They all support arbitrary extensions, similar to TLM2's Generic Payload, allowing for VIP-specific information to be communicated during their processing (e.g. masking fields from a print or compare operation...). Additionally, the printer now has a much more robust mechanism for tracking the structure being printed, making it easy to implement new printers (XML, YAML, JSON, etc.). Registers- Surprisingly few changes here. The most obvious change is that you can now unlock a model after it's been locked, which allows you to remove/replace/etc registers within the model during runtime. For SoCs which support hotplugging, or are generally re-configurable, this was a huge gap in 1.2 functionality. At DVCon 2017 & 2018, there were tutorials which covered all of the above and more, with detailed examples. Aside from #1, most of those changes are for advanced use cases, or providers of infrastructure. Day-to-day users shouldn't necessarily see a drastic change. Looking at the new Accellera implementation specifically, I'd say that the most impactful change is actually in the handling of deprecation. Pre-IEEE, the library would keep code in deprecation for as long as humanly possible so as to limit exposure to backwards incompatibility. Post-IEEE, the library is still using deprecation, but we are limiting ourselves to the previous LRM version. In other words: If something was deprecated as of 1.2, it has been flat out removed in the implementation of 2017. Additionally, the API for enabling deprecated code has been inverted... instead of defaulting to "enable deprecated APIs", the library defaults to "disable deprecated APIs". Hopefully that helps shed some light on your question, -Justin
  5. A common question, and a topic of many discussions within the Accellera UVM Working Group (UVM-WG), was: What should the version of the new UVM release be? Since 1.0-ea, UVM releases have followed the conventions of Semantic Versioning, with MAJOR and MINOR version numbers, and an optional PATCH version letter and/or additional labels. For example, 1.1d-rc2 was MAJOR=1, MINOR=1, PATCH=d, LABEL=rc2. The UVM-WG wanted to maintain semantic versioning moving forward, but at the same time we wanted to indicate what year/revision of the 1800.2 standard we were implementing. The simplest answer was to set the implementation's MAJOR number to the 1800.2 revision year. The library may have MINOR and PATCH updates, but all versions with MAJOR number 2017 will be compatible with 1800.2-2017. If/when the 1800.2 standard is revised in the future, then the MAJOR number will change. That said, why start with 0.9 as opposed to 1.0? This was more of a subjective decision... The 2017 0.9 release is fully functional, but effectively undocumented beyond a basic README.md which describes how to install the kit. Releasing it as "1.0" was viewed as disingenuous, as we knew it was incomplete from a documentation perspective. Why not 0.0 then, or 1.0-ea? Again, subjective. The UVM-WG didn't want to release it under the heading of “0.0”, "beta", "early adopter", "release candidate", etc. because all of those imply a certain lack of functionality. When all was said and done, the UVM-WG settled on "0.9", as it made it clear that something was missing, while not necessarily indicating that the library was in some way "unsafe to use". The UVM-WG is hard at work on "2017 1.0", which will have the complete documentation of the APIs that the implementation supports above and beyond the 1800.2 LRM. In the meantime, we will be actively monitoring this forum, hoping to answer any questions you may have regarding the library. Thanks for your participation! Sincerely, Justin Refice (UVM-WG Chair) & Mark Strickland (UVM-WG Vice-Chair)
  6. 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.
  7. 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!
  8. jrefice

    Typedef for uvm_report_cb missing

    I've opened up a Mantis for your request, thanks! http://www.eda.org/mantis/view.php?id=4996
  9. jrefice

    Problems with starting_phase

    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
  10. 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.
  11. 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.
  12. 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) ?
  13. 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?
  14. jrefice

    Welcome to the UVM 1.2 Public Review

    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!
  15. 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
  16. Version

    429 downloads

    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.
  17. 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.
×