umd-memsys / DRAMSim2

DRAMSim2: A cycle accurate DRAM simulator
http://www.ece.umd.edu/~blj/papers/cal10-1.pdf
258 stars 150 forks source link

DRAMSim2 data_storage branch read mismatch #14

Open adki opened 12 years ago

adki commented 12 years ago

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.

adki commented 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.

dramninjasUMD commented 12 years ago

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.

adki commented 12 years ago

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.

  1. Device configuraiton was "ini/DDR2_micron_16M_8b_x8_sg3E"
  2. Size of memory system was "1024" Megabyte
  3. Step 1: write 9 bytes to 0x0000 with 0x00/01/02/03/04/05/06/07/08
  4. Step 2: read from 0x0000 --> gives correct data
  5. Step 3: write 9 bytes to 0x0100 with 0x02/03/04/05/06/07/08/09/0a
  6. Step 4: read from 0x0000 --> gives incorrect data
  7. 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 '

dramninjasUMD commented 12 years ago

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.?

adki commented 12 years ago

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?