Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

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

janick's Achievements

Advanced Member

Advanced Member (2/2)



  1. Excellent description! This has indeed been fixed and will be in the next release of UVM. See http://www.eda.org/svdb/view.php?id=3586 The default transaction recording will be maintain since it works for the simple, in-order protocols, but a more complex protocol driver will be able to turn it off AT RUNTIME and then explicitly mark the transaction execution time points: task run_phase(uvm_phase phase); seq_item_port.disable_auto_item_recording(); while(1) begin uvm_sequence_base pseq; seq_item_port.get_next_item(req); `uvm_info("Driver", "Received item :", UVM_MEDIUM) req.print(); pseq = req.get_parent_sequence(); accept_tr(req); #2; begin_child_tr(req, (pseq == null) ? 0 : pseq.get_tr_handle(), req.get_root_sequence_name()); #3; fork automatic simple_item tr = req; begin #12; `uvm_info("Driver", "Completed item :", UVM_MEDIUM) tr.print(); end_tr(tr); end join_none seq_item_port.item_done(); end endtask: run_phase
  2. It is not an API that is to be used by users. it is for the model itself to query the configuration information to determine if the coverage model that was generated is to be included or not during construction. It thus allows a model generated with a coverage model to be built without it.
  3. The phase methods without the "*_phase(uvm_phase phase)" signature were never part UVM. They were left there to ease migration from OVM to UVM and are officially deprecated. Thou shalt not use them.
  4. It is used in the CODEC example in the next directory. There are Makefiles for all 3 main EDA vendors in there.
  5. As far as I recall, it was for symmetry. Also, should accessing the phase object be useful/necessary in a future release, this approach made it readily accessible. It would not have been possible to add this argument in a subsequent release as you cannot modify the signature of virtual methods in SV.
  6. That was fixed in Mantis 3770 (http://www.eda.org/svdb/view.php?id=3770). But since is not strictly backward compatible, it is qualified under the macro `UVM_OBJECT_MUST_HAVE_CONSTRUCTOR that is disabled by default. You should enable the macro and modify your code accordingly as it will be enabled by default (with the ability to turn it off for backward compatibility) in the next release.
  7. bad usage: You keep putting a reference to the same object in the FIFO. All entries point to the same object.
  8. It is going to work just fine. Both instances will be 128 bits, but the upper half of the one connected to the 64-bit version will go nowhere and be silently truncated and/or filled with 0's. It may be a good idea to have a configuration variable that specifies the number of bits actually used so you can detect lost bits.
  9. Don't use parameterized width: you won't be able to write generic code for the width-independent code without having to constantly pass parameters through. Not only does it complicates the code, this will slow down your compilation. Much easier to use a MAX_WIDTH macro that the user can redefine at compile-time and let Verilog do its automatic truncation/extension.
  10. Or have each write_*() method put the transaction in an infinite mailbox using try_put() and have the upper layer pull them out of the other end of the mailbox.
  11. If the use independent bus interfaces, they can be kept separate. if they all use the same interface, they have to be contained in a higher-level block.
  12. RAL is blocking because it needs to know the response of a transaction so it can predict its effect in auto-predict mode. Why not simply fork the call to reg.read()/reg.write()?
  13. What Kathleen describes is the predict() method. The set()/get() is used when you want to do batch updates. Instead of causing a write/read operation every time to need to set or read a register, you can set its desired value or get its mirrored value in zero-time, then batch-update the model only for those values that have changed. So you have the choice of two use models: read-write-read-write or mirror-get-set-get-set-update
  14. Yes and no. The stuff that needs to run for the entire duration of the test (e.g. scoreboard, VIPs, transactors) remains in run_phase. But the main body of your test stimulus should be moved to main_phase(): that's what it was designed for.
  15. check_phase(), extract_phase() are functions and thus cannot execute any transactions on the DUT. Use the shutdown_phase() for that purpose.
  • Create New...