Jump to content

jrefice

Members
  • Content Count

    25
  • Joined

  • Last visited

  • Days Won

    2

jrefice last won the day on March 11

jrefice had the most liked content!

About jrefice

  • Rank
    Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for posting! This is a known bug being tracked in https://accellera.mantishub.io/view.php?id=6306... we expect to have it fixed in the next release of the reference implementation (1800.2 2020-1.0).
  2. Ah, I see what you mean by the 64 as opposed to 0, but it's still initialized correctly: // Constructor implementation function uvm_packer::new(string name=""); super.new(name); flush(); endfunction The constructor is just relying on flush() for initialization, so that we don't implement the same code twice. I also agree with the base/implementation comment... that's more legacy than strict intent. It's a good enhancement request for the library though (and the standard in general)! We did it with the uvm_report_server back in UVM 1.2, it makes sense to do it for the policy
  3. @tymonx- Thanks again for the responses, I didn't get a notification about them, otherwise I would have responded a bit faster 🙂 The UVM Packer is not specified as packing bits in any particular format... if the a developer or end user requires a specific format, then they are free to implement their own within the standard. If you've come up with an alternative and you think it'd be useful, please post it! That said, while the format/structure of the bits isn't specified, the LRM is very clear about how packers behave... it seems that the behavior just isn't exactly what you
  4. Thanks for the spirited comments @Tymonx! I'll try and respond to all of your messages in one comment, apologies in advance if it's overly long. To the concerns re: the packing of the m_pack_iter and m_unpack_iter into the byte stream, that is a consequence of how the 1800.2 LRM defines the packer's functionality and compatibility. Specifically sections 16.5.3.1 (State assignment) and 16.5.3.2 (State retrieval), which effectively allow one to dump the packer's state, and safely load it into another packer, regardless of what operations have been performed, and in what order, on the
  5. Thien- Agreed, there's a lot of performance lost in the factory, although we usually see that on the name-based side of town (as opposed to the type-based). Do you have a proposal/code edit that we could inspect and test? This sounds strikingly similar to an enhancement that we've been looking at on the uvm_callbacks side of town as well. -Justin PS- UVM 1.2 is technically deprecated at this point. Any changes would actually be ported forward to the next 1800.2 release.
  6. @thorsten69 : Would it be possible to generate a small testcase illustrating this problem? We're looking into it, but it'd be much easier to traige if we had a failing testcase to execute. Thanks! -Justin
  7. Thorsten- Thanks for the question! I've opened up a mantis to track the issue: https://accellera.mantishub.io/view.php?id=6966 We'll discuss it in today's working group meeting, and update the status as is appropriate. -Justin
  8. Access to the mantis database is restricted to Accellera members. I can tell you that the mantis in question was resolved in the UVM 2017 release, and the bug no longer exists.
  9. 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.
  10. Would it be sufficient to clone the original sequence, and execute the clone in parallel on the TLM model's sequencer/driver?
  11. @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
  12. 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
  13. 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 sim
  14. 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.
  15. 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!
×
×
  • Create New...