Jump to content

Search the Community

Showing results for tags 'bus2reg'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Synthesizable Subset v1.4 Public Review
    • SystemC Verification (UVM-SystemC, SCV)
  • UVM (Universal Verification Methodology)
    • UVM 1.2 Public Review
    • Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • Simulator Specific Issues
    • UVM Commercial Announcements
  • Portable Stimulus
    • Portable Stimulus Discussion
    • IP-XACT Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • OCP (Open Core Protocol)
  • UCIS (Unified Coverage Interoperability Standard)
  • Commercial Announcements
    • Announcements


  • SystemC
  • UVM
  • UCIS
  • IEEE 1735/IP Encryption


  • Community Calendar

Found 2 results

  1. Dear Accellera developers, I have been working with the register model since some weeks. I have tried to understand how the adapters were supposed to be used for all the possible combinations of accesses and register definitions. After those weeks I still have some questions. Lets assume we have a register of 32bits with 3 fields. The databytes per address granularity is 1 databyte per increment of address. In other words, each address increment corresponds to one data byte written . That means that a 32bit register comprises 4 address per register. We have a protocol like AXI that supports byte enable masking. The first field covers only the first data byte of the register. When writing the first field of the register, then our AXI monitor sends one xfer that writes only one byte to the reg_predictor. On the other side, the register predictor that uses the bus2reg function of the adapter, will see that bus access and will try to update the register. I have seen that the UVM library calls bus2reg only once per bus TLM channel transfer. I have seen that the register that outputs bus2reg starts a bus collection process. I have seen that the register update will be done if: 1) the address is inside a register address: if (rw.addr == map_info.addr) begin 2) the bus collector reached the number of bytes needed to complete a register: if (predict_info.addr.num() == map_info.addr.size()) begin I have seen that in case the bus collector doesn´t have all the needed xfers to complete a register (if (predict_info.addr.num() == map_info.addr.size()) begin), a break will stop the loop over the addresses. From the previous information, I guess that the intention with the "write" function of the predictor was, that the monitor provides as many xfers that the collector will always complete all the bytes inside a register. Is that correct? Now come the question with the summary. The write function of the register predictor will be called only once. The bus2reg of the register predictor will be called only once. The collector of the write function in the register predictor will collect only once. The condition: "if (predict_info.addr.num() == map_info.addr.size()" will never be true because the register collected field has a size of 1 byte and the total register has a size of 4 bytes. At least it will not be true until the 4 predict_info addresses are received in the write function. How it is supposed to update fields within the UVM register model? We think we can come around to this problem if we call the write() function for each byte with 3 byte_enables set to zero and one set to 1. Is the monitor supposed to split the 32bit AXI data on the bus into bytes to send those to the register predictor? Could you explain me the concept behind field write and field update of the register model in this context. Are my assumptions and understanding wrong? Any help would be appreciated. Do you have an example for this situation? Looking forward your answer Joachim and Jonathan
  2. In uvm_reg_map::do_bus_read() task, after the call to adapter.bus2reg() function, do_bus_read() function checks for any Xs in data field. Code from uvm_reg_map: uvm_reg_bus_op rw_access; uvm_reg_data_logic_t data; data = rw_access.data & ((1<<bus_width*8)-1); rw.status = rw_access.status; if (rw.status == UVM_IS_OK && (^data) === 1'bx) rw.status = UVM_HAS_X; Here, rw_access.data is of type "bit" and is assigned to data which is of type "logic". and then data is checked for Xs. But, as rw_access.data is "bit" type, it will never contain Xs or Zs. As a result, data will never have Xs, so rw.status will not set to UVM_HAS_X. So even if bus2reg function samples Xs from the bus, those Xs never make upto tasks in uvm_reg_map class. Some supporting code:: uvm_reg_defines.svh: `define UVM_REG_DATA_TYPE bit uvm_reg_model.svh : typedef `UVM_REG_DATA_TYPE unsigned [`UVM_REG_DATA_WIDTH-1:0] uvm_reg_data_t ; uvm_reg_item.svh: typedef struct { uvm_access_e kind; uvm_reg_addr_t addr; uvm_reg_data_t data; int n_bits; uvm_reg_byte_en_t byte_en; uvm_status_e status; } uvm_reg_bus_op; In my testbench, I want uvm_reg_map to set the status to UVM_HAS_X whenever data received for a register read transaction from DUT is X. How do I achieve that?