DRAMSim2
DRAMSim2 copied to clipboard
DRAMSim2 data_storage branch read mismatch
DRAMSim2 data_storage branch seems not work properly. For two consecutive Read-After-Writes, the second read does not return what has been written.
//----------------------------- first RAW ----
void *write_buf = malloc(32);
for (int x=0; x<32; x++) ((unsigned char*)write_buf)[x] = x;
mem->addTransaction(true, 0x9000, write_buf, 32);
for (int i=0; i<5; i++) { mem->update(); }
mem->addTransaction(false, 0x9000, NULL, 0);
for (int i=0; i<5; i++) { mem->update(); }
//----------------------------- second RAW ----
write_buf = malloc(8);
for (int x=0; x<8; x++) ((unsigned char*)write_buf)[x] = x+16;
mem->addTransaction(true, 0x9010, write_buf, 8);
for (int i=0; i<5; i++) { mem->update(); }
The above reports as follows. dramsim_test main() ini/DDR2_micron_16M_8b_x8_sg3E writing vis file to ../results/resultsfilename/DDR2_micron_16M_8b_x8_sg3E/2GB.1Ch.2R.scheme2.open_page.512TQ.512CQ.RtB.pRank.6.vis [Callback] write complete: 0 0x9000 cycle=0 [Callback] read complete: 0x9000 data='00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ' [Callback] write complete: 0 0x9010 cycle=0 [Callback] read complete: 0x9010 data='00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f '
As it shows, values returned from address 0x9010 differ from what has written.
Well, I think I figure it out. Read transaction always returns a block data. So read_complete call back carries 32-byte data in its argument, while write transaction request (addTransaction(true, ...)) carries data that will be written regardless its starting address. However I still have questions regarding arguments as follows.
- addTransaction() for write should be given a fresh buffer pointer that has been just allocated, and it will be freed somewhere inside, i.e., user should not free it. Is it correct.
- addTransaction() for read does not need any buffer to carry read data after completion so the buffer pointer should be NULL. Is it correct? Or, is it possible to pass pointer for data buffer when add read transaction through addTransaction()? If any, how?
- addTransaction() for read do not care of number of bytes to read, since it always read a block, i.e., 32-byte for DDR2. Is it right?
- read complete callback passes data buffer pointer and it may not need to be freed by user. Is it correct?
Thanks in advance.
As far as the RAWs, the data being returned is still incorrect? I thought I tested this case somewhat thoroughly, but I'll have to look at it again.
For the buffer issues, see my answers in the other github issue. You're right about the 32-byte block, but more specifically it's the size of a burst (i.e. for BL=8 in DDR3, you'll get back a 64 bye data block whereas for DDR2, with BL=4, you get back a 32 byte data block).
As of right now, a read will always generate a new DataPacket and fill it with the data, so passing in your own data buffer will be a memory leak.
I tested RAW case again and it seems something wrong. Following is the testing scenario with 'example_app' in the DRAMSim2 data_storage branch. It is a bit urgent to me and if someone can fix it or give me an idea how/what to do, it would be very grateful.
- Device configuraiton was "ini/DDR2_micron_16M_8b_x8_sg3E"
- Size of memory system was "1024" Megabyte
- Step 1: write 9 bytes to 0x0000 with 0x00/01/02/03/04/05/06/07/08
- Step 2: read from 0x0000 --> gives correct data
- Step 3: write 9 bytes to 0x0100 with 0x02/03/04/05/06/07/08/09/0a
- Step 4: read from 0x0000 --> gives incorrect data
- Step 5: read from 0x0100 --> gives correct data
-------------- part of log -- [Callback] write complete: 0 0x0 cycle=10 [Callback] read complete: 0x0 b:32 data='00 01 02 03 04 05 06 07 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ' [Callback] write complete: 0 0x100 cycle=22 [Callback] read complete: 0x0 b:32 data='00 02 03 04 05 06 07 08 09 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ' [Callback] read complete: 0x100 b:32 data='02 03 04 05 06 07 08 09 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '
To make things easier, could you either email me your test program to dramninjas at gmail or post it in a pastebin/github gist/etc.?
I got an idea, which uses read/write completion callback functions. Actual read/write behavior can be implemented in the read/write completion callbacks. By doing that, the normal DRAMSim2 can be used for data-storage version. Obviously, the callback function needs to handle system memory allocation and deallocation. There is one assumption where all transactions should be atomic, i.e., no transactions can be merged by DRAMSim2. How about this idea?