Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by janick

  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.
  16. Parameters used for sizing interfaces are like viruses! They propagate to every variable and environment that must use them. Much better to rely on Verilog's automatic resizing and be done with it. That way, you can write width-generic code. http://www.vmmcentral.org/vmartialarts/2008/07/size-does-matter/
  17. uvm_mem is just a front-end to the physical bus or the backdoor access mechanism to your memory model. It does not store any actual memory content for the exact reason that memory can be huge. It simply computes address offsets and translates wide memory words into smaller accesses if the data bus is narrower. So you simply need to decide on the granularity of your memory accesses (that would be the width of the memory and need mot match the width of the data bus) and how many location it contains (that would be its length) which will determine how many addresses it occupies in the address map.
  18. The warning is an artifact of the missing return statement. If a map can successfully be found, the access should proceed without any messages.
  19. Simplest would be to attach a post-write callback on all of the registers that can be the target of a broadcast write and do a predict() on other registers that should be written by the same.
  20. I agree that a return statement is missing in uvm_mem.svh at line 1121. I have filed a mantis for this one: http://www.eda.org/svdb/view.php?id=4340 As for your statement that "in cases where a memory belongs to multiple maps, the read/write command should be forced to provide a map.", I have to disagree for reuse reasons: Assume some block-level code where the memory is only in one map, and the memory accesses are written without specifying a map (because there is only one). The block is subsequently modified to add a new address map (or instantiated in a multi-map block [not yet supported BTW -- see http://www.eda.org/svdb/view.php?id=4009]), all these accesses will now have to be modified to explicitly specify a map to use.
  21. On a related note: it allows context to be defined by where the sequence is running, not its hierarchical name. http://www.uvmworld.org/forums/showthread.php?813-Virtual-Sequences-and-Factory-Overrides
  22. Call uvm_reg_map::do_write() on the physical interface you want to perform the built-in front-door access.
  23. All hierarchical names and parent relationships in UVM are determined at creation time. Because the virtual sequence is creating the non-virtual sequence, it (not the non-virtual sequencer where it will be running) is the parent of the sequence. Hence it is the hierarchical path that will control factory override. You could provide your own context based on the executing sequencer by calling the factory explicitly instead of relying on the macros or uvm_sequence_base::create_item() but you'll break what other UVM users expect as the "normal" behavior of the sequence item contexts.
  24. Cliff, I'm going to have to take my black marker to your new UVM Guidelines fridge magnet too?? Nope. Use them to get sequencer-context variables. You want to avoid repeatedly getting variables from the config/resource DB if they are not going to change or be identical across different sequences. A prime example is for a virtual sequencer/virtual sequences. The virtual sequencer has variables referencing the sub-sequencers. The virtual sequences then use them through a p_sequencer reference to coordinate the execution of sub-sequences on sub-sequencers.
  25. Because it has to be done once all of the maps are loaded and from the top-most block only because it builds the address-to-register index for all top-level address maps.
  • Create New...