Jump to content

petermonsson

Members
  • Posts

    59
  • Joined

  • Last visited

Everything posted by petermonsson

  1. Hi Manju, I am afraid that there is no such thing for the UVM factory. What would you use it for? Best Regards Peter
  2. Hi arno, A humble question: What are you looking for in the check phase? Please note that the documentation gives you no guarantees on what happens if a timeout occurs, nor does it imply that it is up to you to decide whether a timeout is an error or not. You think that it is up to you to decide whether a timeout is an error or not, I think that a timeout is always an error, but the documentation does not prove any of us right. Best Regards Peter
  3. Hi mrforever, This is how it is done in the in the ubus integrated example which is in the UVM distribution. I personally do it a little differently by decoding the request in the reactive driver, but this is just an implementation detail. I hope that this helps. Best Regards Peter
  4. Hi Harry, Correct, that would be a custom implementation for the registers where you have this behavior. I can't comment on the enhancement request; this is outside my expertise. Best Regards Peter
  5. Hi, In UVM a configuration is meant to apply to a component, not an object. I believe that you should try to use a sequence with your transaction. In a way, one could say that a sequence is to a transaction what a configuration is to a component: cfg -> driver seq -> transaction I hope this helps Peter
  6. Hi, My suggestion is to use option A and B the following way: 1) Identify all conversions from X to Y in your scoreboards. Almost all scoreboards will do some type of conversion. 2) Factor out all conversions from X to Y into their own components (for example a predictor) 3) For the block level test bench take the simple predictors and connect them with a comparator to form a block level scoreboard 4) For the chip level test bench chain the appropriate components and match them up with a comparator This is of course easier said than done. I hope this helps Peter
  7. Hi Harry, I think that this is outside basic UVM and IP-XACT terminology, but have a look at the UVM Register Callbacks (uvm_reg_cb) http://www.vmmcentral.org/uvm_vmm_ik/files3/reg/uvm_reg_cbs-svh.html and the uvm_reg_field:: predict method. Combining those two may be able to do it. I hope this helps. Best Regards Peter
  8. Hi joy, As a minimum you will need one agent per standard interface on boundary of the system which you're trying to verify. On top of that you will want an agent per interface which you want to access through hierarchical references inside the system. Here are two examples: AHB to APB bridge: You will need an AHB Master Agent and an APB Slave Agent as a minimum. Since someone in your organization is developing a AHB to APB bridge, your organization is going to need an AHB Slave Agent and an APB Master Agent soon, so you should strongly consider doing those as well at the same time. AXI, AHB, APB interconnect (memory access system): You will need a master and a slave agent for each of the protocols that hook up to the interconnect as a minimum. I hope this helps Peter
  9. Hi, ubus_base_sequence is a virtual base class which is never directly bound to the ubus_master_sequencer. Instead a specific subclass such as the read_modify_write_seq in examples/ubus/integrated/examples/ubus_example_master_seq_lib.sv is bound to the sequencer. You can see an example where read_modify_write_seq is bound to the sequencer in the test_read_modify_write class in examples/ubus/integrated/examples/test_lib.sv. Here the connection is made through the uvm_config_db. uvm_config_db#(uvm_object_wrapper)::set(this, "ubus_example_tb0.ubus0.masters[0].sequencer.run_phase", "default_sequence", read_modify_write_seq::type_id::get()); There are other ways such as seq = read_modify_write_seq::type_id::create("seq"); uvm_config_db#(uvm_sequence_base)::set(this, "ubus_example_tb0.ubus0.masters[0].sequencer.run_phase", "default_sequence", seq); or in the run_phase: seq = read_modify_write_seq::type_id::create("seq"); seq.start(ubus_example_tb0.ubus0.masters[0].sequencer); I hope that this helps. Best Regards Peter
  10. Hi, I believe this to be a bug: http://www.eda.org/svdb/view.php?id=4297 Best Regards Peter
  11. Hi, Thanks. Again, I haven't had any experience with this, so I can't help you. The only thing that I've used is standard SystemVerilog Assertions (I haven't even used the UVM reporting for errors). I will get back to you when I find some time for this. Best Regards Peter
  12. Hi Verifier, I don't have a full solution, but here is an idea. Create a base virtual sequence which can start a register sequence. For each agent + uvm_reg_map, create a subclass of the base virtual sequence which connects the register sequence to the specific agent. Use +uvm_set_inst_override or +uvm_set_type_override command line options to override the instantiation of the base virtual sequence in your environment to a specific subclass. It is late for me, so I'm not sharp enough to give you any code, but does this help you some of the way? Best Regards Peter http://www.vmmcentral.org/uvm_vmm_ik/files3/base/uvm_cmdline_processor-svh.html
  13. Hi, I haven't seen anything new from OVL since 2008. Where do you see the 2011 release? There is very little information on combining assertion based verification with constrained random verification, unfortunately. I don't know why. Best Regards Peter
  14. Hi Verifier, Have you found a solution to this yet? If not, is it a completely different register model for each agent or is it just a different uvm_reg_map? Best Regards Peter
  15. Hi Itsmyturn, uvm_config_db is meant for pretty static functionality. I would suggest that you use TLM to pass information from the response monitor to the request driver. Best Regards Peter
  16. Hi itsmyturn, It depends. What protocol are you implementing. If it is something like AXI I would put the request and response handling logic inside a single driver because an AXI agent is one conceptual unit. Best Regards Peter
  17. Hi Subin,, Have a look at the APB agent in the examples/integrated in the UVM distribution. If you're completely new to UVM, I suggest that you read the UVM Users Guide. Best Regards Peter
  18. Hi wuddi, Please see the documentation for get and get_next_item: http://www.vmmcentral.org/uvm_vmm_ik/files3/tlm1/sqr_ifs-svh.html#uvm_sqr_if_base#%28REQ,RSP%29.get_next_item "Once get_next_item is called, item_done must be called to indicate the completion of the request to the sequencer. This will remove the request item from the sequencer fifo." "When get is called, item_done may not be called. A new item can be obtained by calling get again, or a response may be sent using either put, or uvm_driver::rsp_port.write()."
  19. I've added your suggestion to the UVM Issue tracker. You can see the status here: http://www.eda.org/svdb/view.php?id=4258
  20. Your driver needs to call seq_item_port.item_done() when the transaction is done. Are you sure that this is happening?
  21. Hi, This is a problem in the User Guide. The User Guide should not recommend people to use deprecated features. I have reported the bug to the tracker http://www.eda.org/svdb/view.php?id=4198 Please note that User Guide only changes on feature releases, so the next User Guide release would be for UVM 1.2 Best Regards Peter
  22. 760 downloads

    A simple integrated example test bench for people who want to learn UVM. This is pre-alpha, unreviewed and buggy code. If you use this as a basis for anything other than reviewing it for bugs then you're on your own. If you tape-out something based on this you will waste time and money. See the README for more information
  23. Hi, The UVM RAL system doesn't provide direct burst access. A way to inject burst access is to save the address of the current transaction inside the low level driver and compare this address with the address of the next transaction. For I2C specifically, you'd need to put the item_done(), get_next_item() part right between the ACK/NACK and the potential STOP condition. I hope this helps Peter
  24. Hi, I see two options: 1) Declaring a RO and WO register sharing the same address (UVM User Guide section 5.7.5) 2) Declaring the register with NO_REG_TESTS In both cases you will want to verify the shadow functionality seperately. Best Regards Peter
  25. Hi David, Thanks for your bug report. It is registered under http://www.eda.org/svdb/view.php?id=4091. Best Regards Peter
×
×
  • Create New...