Jump to content

Search the Community

Showing results for tags 'bus2reg'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Accellera Systems Initiative
    • Information
    • Announcements
    • In the News
  • SystemC
    • SystemC Language
    • SystemC AMS (Analog/Mixed-Signal)
    • SystemC TLM (Transaction-level Modeling)
    • SystemC Verification (UVM-SystemC, SCV, CRAVE, FC4SC)
    • SystemC CCI (Configuration, Control & Inspection)
    • SystemC Datatypes
  • UVM (Universal Verification Methodology)
    • UVM (IEEE 1800.2) - Methodology and BCL Forum
    • UVM SystemVerilog Discussions
    • UVM Simulator Specific Issues
    • UVM Commercial Announcements
    • UVM (Pre-IEEE) Methodology and BCL Forum
  • Portable Stimulus
    • Portable Stimulus Discussion
    • Portable Stimulus 2.0 Public Review Feedback
  • SystemVerilog-AMS
    • Verilog-AMS 2023 Public Review
  • IP-XACT
    • IP-XACT Discussion
  • SystemRDL
    • SystemRDL Discussion
  • Clock Domain Crossing (CDC)
    • CDC Draft LRM Release Discussion
  • IP Security
    • SA-EDI Standard Discussion
    • IP Security Assurance Whitepaper Discussion
  • IEEE 1735/IP Encryption
    • IEEE 1735/IP Encryption Discussion
  • Commercial Announcements
    • Announcements

Categories

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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Jabber


Skype


AIM


Yahoo


ICQ


Website URL


MSN


Interests


Location


Biography


Location


Interests


Occupation


Company

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?
×
×
  • Create New...