Jump to content

itsmyturn

Members
  • Content Count

    13
  • Joined

  • Last visited

  1. Yeah, I was doing that. I figured out that one of my agent's clock wasn't being driven. Thanks!
  2. I think your monitor checking code itself can be made conditional based on a configuration variable in your agent cfg object. You can disable the monitor checking by default, and then when your initialization/configuration sequence is done, your sequence can get the env/agent cfg object and enable the checking.
  3. Instead of using the database for each config parameter of your agent, it might be better to have a config object for the entire agent. Then, you have a virtual method that actually configures the agent (initializes all the config parameters in the agent cfg object). Then your test can simply extend that virtual method and reconfigure it as required.
  4. My sequence is calling the `uvm_send macro and it never returns from that macro. I added a uvm_info message in that macro (in uvm_sequence_defines.svh) just before calling finish_item, and I also added some uvm_info messages in the finish_item (defined in uvm_sequence_base.svh). I see that the message before calling finish_item is displayed. However, the first uvm_info message from finish_item is not being displayed. I don't know where that finish_item call is going, but it's definitely not going to the task defined in uvm_sequence_base.svh in my case. Is there something I'm missing here?
  5. I have an array of IDs in my agent. When a packet is sent to the DUT with one ID, that ID can no longer be used for newer packets until a response with the same ID comes back from the DUT to the response monitor. In my implementation, the response monitor forwards this response to the scoreboard. Now, I want the scoreboard to update the array of usable IDs in the agent with the ID that just got freed. Can I use uvm_config_db for this?
  6. I have an agent (seqr, driver, monitor) that drives requests to my DUT. The DUT sends out-of-order responses back to the env at arbitrary times. The responses are matched with the requests by matching the IDs. The agent can only drive a new request with those IDs for which there are no pending responses from DUT. I need help on how to tell my active agent's sequencer to only use those IDs that don't have pending responses. The response has a lot of other info too (along with the ID). So, I'm creating another agent (passive) to monitor the responses on the resp interface. I was thinking about something like this: Passive agent's monitor sends the DUT response back to the scoreboard. Then, the scoreboard updates the database saying that the ID got freed (and the active agent's requests are constrained to use the available IDs in the database). This looks like a lot of database accesses to me. Is there a better way of doing this (for eg: scoreboard sends the resp ID to the active agent's sequencer on a TLM interface and that is used for constraining the req's IDs?) ? Thanks
  7. For sequence items, we can either use uvm_create/do or start_item/finish_item. Is know that uvm_create allows late-randomization as compared to uvm_do. Is start_item/finish_item deprecated? I'd like to learn it right when I'm learning. So, can someone help me with the commonly-used and suggested method? Thanks in advance.
  8. I probably don't want any randomization/intelligence in my driver. But having the delay field as part of transaction sounds like a good way of doing it. I'll try that. Thanks!
  9. I have to insert random delays between the transactions in the sequence. From some basic reading that I've done, I felt like the approach to follow is to have a driver's run task similar to this (say no response): task run(); forever begin seq_item_port.get_next_item(req); driveTxn(req); seq_item_port.item_done(); dlyCfg::get_config_int("txnDelay", this.txnDelay); repeat (this.txnDelay) @(posedge vif.clk); end endtask : run If I followed this approach, after every transaction, both driver and sequence access the database. Won't it slow down things? I'm wondering if there's a better approach that's optimal/cleaner. Thanks in advance.
  10. Even I doubted whether amitrana's comments were correct, as I saw uvm_object type objects being casted to VIF container objects everywhere in the UVM manuals/books. But, I wasn't quite sure if I was in a place to comment. Anyway, thanks for the detailed explanation. I didn't know that a derived guy can be assigned to base class handle directly. Thanks again.
  11. Looks like I landed in the right place. Thank you all for the replies. They're quite helpful.
  12. Dave, thank you so much for the prompt reply. It did the trick. I hate to say that I spent a couple of hours fighting with that casting issue. I still don't understand why that didn't work. Can you think of a reason why that casting didn't work? Thanks
  13. My code for the driver's connect phase is shown below. I'm creating a simple VIF container object and setting it as a DB object. When I try to retrive it from the driver, I do get the object, but it seems to be of a different type, and my simulation fails at the casting step in the driver. Can someone help me with this. This is my first attempt with UVM. So, it might be a very simple mistake. Any help in this regard is appreciated. I have an initial block in my TB that does something like initial begin typedef myvif_container #(virtual myInterface) myvif_container_t; myvif_container_t myvif_container_h; myvif_container_h = myvif_container_t::type_id::create("myvif_container_h"); set_config_object("*.*driver", "myvif_container", myvif_container_h); .... end function void connect(); uvm_object tmp; typedef myvif_container #(virtual myInterface) myvif_container_t; myvif_container_t myvif_container_h; if (!(get_config_object("myvif_container", tmp))) begin `uvm_fatal(get_type_name(), "VIF container not found") end if (tmp == null) begin `uvm_fatal(get_type_name(), "VIF container is null"); end if (!($cast(myvif_container_h, tmp))) begin `uvm_info(get_type_name(), $psprintf ("container type is %s", tmp.get_type_name()), UVM_NONE); `uvm_fatal(get_type_name(), "Interface container different type") end endfunction : connect class myvif_container #(type VIF=int) extends uvm_object; `uvm_object_param_utils (myvif_container #(VIF)) VIF m_vif_h; function new (string name="vif_container"); super.new(name); endfunction : new endclass : myvif_container
×
×
  • Create New...