Jump to content

Tom_Alsop

Members
  • Content Count

    3
  • Joined

  • Last visited

Everything posted by Tom_Alsop

  1. If you are using UVM and you find a bug, there is a formal way to request a fix. The same applies for requesting enhancements. This is done through the eda.org mantis database for VIP. Before you read on, however, please understand that any issues cited on Mantis will be seriously scrutinized by the VIP TSC Accellera committee who owns the UVM. So please absolute due diligence is required to make sure you have a real bug or that your enhancement request will be seriously considered. One suggestion is to use these forums to open up the discussion _before_ submitting anything onto Mantis. You can also use the VIP TSC reflector (mailing list) to post your issue for discussion. Just send your issue to vip-tc@lists.accellera.org and someone will answer it. If you find out that there truly is a bug or that your enhancement request will benefit many users, then you’ll want to get it filed in the UVM Mantis database so that the committee can process it. You can report the issue in one of four ways. Send mail directly to someone you know in the VIP TSC who participates in the committee and ask that they file the issue for you. (Preferred method) Send mail directly to the VIP co-chairs (Hillel Miller and Thomas Alsop) and ask them to file the issue. Use this email address  vip-tc-chair@lists.accellera.org Send mail to the reflector (vip-tc@lists.accellera.org) requesting that an issue be filed.You can get ‘reporter’ access to the VIP (UVM) Mantis DB. Just send me mail (thomas.r.alsop@intel.com) giving me your first & last name and email address and tell me that you would like ‘reporter’ access. I’ll set up a Mantis account for you and this will give you a username and password. From there you go to the Mantis site and enter the issue as described below. (Please use this last method if you plan on filing multiple issues over time). Filing an issue in Mantis: Click on the link called ‘UVM Bug Tracking’ on the UVMWorld.org main webpage (left hand panel) or use this direct link: http://www.eda.org/svdb/main_page.php Log into Mantis with your reporter account. Choose ‘Report Issue’ from the top panel and start filling out the Mantis form. Don’t worry about filling out all the fields, only fill out the following: The Category: Choose either the base class library (BCL), the Reference Guide (RefGuide), or the UsersGuide depending on where the issue is located. Severity and Priority: Should be obvious, you decide. Product Version: At this time choose ‘1.0’ for enhancements or ‘1.0EA’ for bugs/errata/clarification Fill out the Summary Fill out the full Description of the issue. Choose an issue Type: Errata (bug), Clarification, or Enhancement Hit the ‘Submit Report’ button at the bottom of the page. That’s it. The Accellera committee will periodically review all Mantis items and ensure they are dealt with appropriately. –Thomas Alsop (vip-tsc co-chair)
  2. I just want to address some concerns which I have heard from end users who have either adopted the UVM 1.0 EA release or are considering using it on an upcoming project. I have heard some concerns about the “EA – Early Adopter†tag on the release name. First, I would like to make it clear that the UVM library code is derived from the OVM2.1.1 release and except for the 3 new features which have been added, the rest of the library code has not been changed except for the changing of the symbols from ovm_* to uvm_*. Therefore only the 3 new features listed in the release notes should be consider as new “Early Adopter†features. In addition, the plan is for the 1.0EA release to be backward compatible with the upcoming UVM 1.0 release unless there is a really compelling technical reason which would require making some small backward incompatible changes. I know this sounds like a loop hole, but there are two reasons for making this statement. One, we want all end users to understand that the VIP committee is making every effort to keep every release fully backward compatible. Second, there are sometimes very legitimate and persuasive reasons to selectively choose that some features not be backward compatible. However, at this point in time, we are not aware of any new features being planned for UVM 1.0 that should introduce any backward incompatibility. For your reference here are the main additions currently being worked on for the UVM 1.0 release: - Register package: This package will sit “on top†of the UVM class library so it should not have any impact on the current class library. - Run-time phases: The requirements are being gathered for this new feature now, but there has already been a lot of discussion on how this feature could be added without introducing any backward incompatibility. - TLM 2.0: It has already been decided by the committee that UVM will continue to support TLM 1.0, so any TLM2.0 support should be additive. Furthermore, anything that might be introduced that could cause backward incompatibility, would be heavily weighed, looking at the pros and cons and the impact to current users, and would not be something that is lightly considered. Keep in mind that the majority of the VIP TSC Committee consists of end user members, so their voice is the strongest on this topic. The bottom line is the UVM 1.0 will be backward compatible with only the possibility of some highly weighed minor exceptions, and if any such change was introduced, the library would provide a facility for supporting user code which has been written on top of the UVM1.0 EA release. Thanks, Thomas Alsop (vip-tsc co-chair)
  3. The quick answer is the committee doesn't know yet. We want to allow the next release to be feature driven, not date driven. As Adam mentioned we are looking at several features and walking through the requirement lists for those features and building them up by collecting feedback from committee members. We have other features beyond Register Packages and TLM2 that are also being discussed, Phasing enhancements being the other big one. The F2F we are having in early August will give us a good idea of the release date. My gut estimate is Q4 of this year simply because of the amount of work needed to gather the appropriate list of requirements, sanitize them, vote on them, and create a spec that everyone mostly agrees to. All that has to be done before we implement the changes. I'd like to see the requirements list done and solidified by the end of the August, Specs done in Sept, and implementation/testing over the next 2/3 months. Let me be clear that this is just my personal take and may only amount to a wish. Ask us for an update in early August. Hope this helps, -Tom
×