• Content count

  • Joined

  • Last visited

  1. What you are trying to do is create a switch which takes separate transactions (i.e. sequence items A, B ,C) and route to same interface. Please correct if I m wrong here in understanding the problem statement. In addition to what Erling has suggested, I would suggest using a higer level sequence item class which is parent to A, B and C. Then use TLM fifo of type parent class to route the transactions. Therefore a component that takes transaction items as they come from A, B,C and just route to one FIFO and driver could fetch it from it.
  2. Phil, No, This is not the purpose of translation. The translation is always for the interface serving the registers in a DUT. Hence a simple register sequence item is converted to a bus item that could be AHB/WB or any proprietary bus for register read/write. Therefore its a reusable code for most of your DUTs having similar register interfaces. What you intend to do is percolate the register writes to your bus drivers which make use of the register values. This is a specific implementation that you would need to sort out inside testcases which would run the 2 sequences independently. A way which we use commonly for this is : 1) Use configure/post_reset/pre_main etc phase to run a generic register sequence. i.e. Randomize the register model and write the entire map to DUT based on certain constraints. 2) In other phase occurring after the above , use the already configured regmodel property inside your driver and perform the usual transactions. The sequence item thus would be independent of the property and would be taken care by the driver instead Or as in your case inside the testcase in a different phase use `uvm_do_with and use inline constraint e.g. `uvm_do_with(req, {req.xfer_size == ctrl.mod1.ctl.xfer_size.get();}) Hope it helps! Thanks, Mehul
  3. Better way would be to use different environment classes and instantiate the environment top extended from uvm_top based on the test that you want to run. 1) uvm_vip_env (back to back UVM vips) connected and use them in the uvm_test classes 2) uvm_dut_env (UVM vip instantiated to be connected with DUT) and then use that with the uvm_test classes. You are actually defeating the purpose of UVM plug-n-play by creating verilog over uvm vips and then instantiating them conventionally. Thanks, Mehul
  4. Hi Kumar, It would be great if you could share your reg2bus adaptor code. The issue seems to be while converting the reg item to AXI item for the transaction. Thanks, Mehul
  5. Version


    UVM user guide explains in detail how a model is integrated for a parallel interface. This paper discusses the use of UVM register classes when verifying register accesses through a serial port (e.g., JTAG) on the DUT.