Jump to content

Justin Refice

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Justin Refice

  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 (State assignment) and (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. @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
  6. 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
  7. 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.
  8. Would it be sufficient to clone the original sequence, and execute the clone in parallel on the TLM model's sequencer/driver?
  9. @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
  10. 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
  11. 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
  12. 472 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
  13. 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 42
  • Create New...