clacasse Posted August 10, 2011 Report Posted August 10, 2011 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? Thanks, Chris Quote
janick Posted August 11, 2011 Report Posted August 11, 2011 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. Quote
clacasse Posted August 22, 2011 Author Report Posted August 22, 2011 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: +UVM_TESTNAME=mem_reg_model_test +UVM_VERBOSITY=UVM_HIGH +define+UVM_REG_DATA_WIDTH=128 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: reg_model.mem.burst_write(.status(status), .offset(32'h0000_0000), .value(value)); 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. Thanks, Chris Quote
clacasse Posted October 18, 2011 Author Report Posted October 18, 2011 Janick, Have you been able to reproduce with the example I attached? Thank you, Chris Quote
Recommended Posts
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.