Open adki opened 12 years ago
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.
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.
-------------- 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?
DRAMSim2 data_storage branch seems not work properly. For two consecutive Read-After-Writes, the second read does not return what has been written.
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.