Jump to content

[uvm_mem/uvm_reg_map] Memory burst_write question...

Recommended Posts

I am trying to use the burst_write task to write to a 128 bit wide memory. I have included some lines that show how I setup the memory, etc.

The `UVM_REG_DATA_WIDTH define is set to 128.

Memory creation... (128 bits wide, 0x200_0000 locations of 128 bits.)

mem = new($psprintf("mem[%0d]",i), 0x200_0000, 128, "RW", UVM_NO_COVERAGE);

Memory map creation... (16 byte wide memory map)

memory_map = create_map($psprintf("memory_map[%0d]",i), 'h0, 16, UVM_LITTLE_ENDIAN, 1);

The burst_write appears to send the correct data for the 1st bus write, but all of the other bus writes have their data zeroed out. I believe this is due to the following code in the uvm_reg_map::do_bus_write task:

data = (value >> (curr_byte*8)) & ((1'b1 << (bus_width * 8))-1);

The curr_byte value is not reset inside of this task, it is only incremented by the number of bytes written. So when this task begins breaking down the burst into individual transfers to be transformed by the adapter (adapter::reg2bus), all data after the 1st full bus width will be shifted to zero.

Is this a bug, or have I done something wrong here? Has anyone had success using the burst_write task to write to a uvm_mem, and if so how were you able to do so?



Link to comment
Share on other sites

There are many variables that can influence the behavior: address granularity, size of the data bus, size of the memory words, size of the burst, etc.... Further, UVM_REG_DATA_WIDTH defines the maximum size of field and memory locations, not the width of the data path.

I'm afraid you do not provide enough information to help you. For quicker resolution, please provide a testcase with a description of the expected behavior vs the observed behavior.

Link to comment
Share on other sites

  • 2 weeks later...

I have attached an example of how I am using the memory model, and how it is behaving. The tarball includes an "example" directory that contains all of the SV files. The "log" directory has a ".save" log file that has what I would have expected the register model to have done with the burst, while the ".log" file is what the current UVM register model implementation performs. The test was run with the following parameters:




In this example, the memory was defined to have 4k locations, each 128 bits wide. It was mapped into a map at base address 0, 16 bytes wide, little endian, and byte addressable:

mem = new("mem", 4096, 128, "RW", UVM_NO_COVERAGE);

this.default_map = create_map("default_map", 'h0, 16, UVM_LITTLE_ENDIAN, 1);

The sequence executed in the test fills an array of type uvm_reg_data_t, and executes a burst_write:




You will notice, looking through the log files, that the current uvm_reg_map implementation misses the 2nd 128 bit word as well as zeroing out all of the data for words other than the 1st.



Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...