Address not aligned warnings from DRAMSim2 with Marss

[pjh]

I've been using DRAMSim2 with the Marss simulator for a few days and am currently trying to configure the machine that I want to be simulated. I have been getting some warnings and errors from DRAMSim when I change some of the machine configurations, and I'm not sure if it's a DRAMSim or Marss issue or configuration issues on my part. I've found that I can reproduce the warnings using one of the example machine configurations provided in Marss' default.conf file. These are the steps that I'm taking to reproduce the problem from scratch (worked on 6/21/12):

> git clone git://github.com/dramninjasUMD/marss.dramsim.git
> git clone git://github.com/dramninjasUMD/DRAMSim2.git
> cd DRAMSim2
> make libdramsim.so
> cp system.ini.example system.ini
> cd ../marss.dramsim
    (At this point, I first have to edit the qemu/SConstruct file: LINKFLAGS was not being set correctly, so I replaced $LINKFLAGS in the qemu_bld_action line with "-ldramsim -L/path/to/DRAMSim2 -Wl,-rpath=/path/to/DRAMSim2")
> scons c=2 dramsim=/path/to/DRAMSim2/
> ldd qemu/qemu-system-x86_64 | grep dramsim
> edit test.cfg:
   -machine private_L2
   -corefreq 2000000000
   -bench-name test
   -stats test.stats
   -logfile test.log
   -loglevel 6
> qemu/qemu-system-x86_64 -hda /path/to/ubuntu-kvm-natty-amd64.raw -m 1024 -simconfig test.cfg

In my emulated system I now run a program that switches to simulation mode, and I see the following output:

PTLCALL type PTLCALL_ENQUEUE
MARSSx86::Command received : -run
== Loading device model file
'../DRAMSim2/ini/DDR3_micron_8M_8B_x16_sg15.ini' ==
== Loading system model file '../DRAMSim2/system.ini' ==
===== MemorySystem 0 =====
CH. 0 TOTAL_STORAGE : 1024MB | 2 Ranks | 4 Devices per rank
 Completed             0 cycles,             0 commits:         0 Hz,      0 insns/sec: rip ffffffff81037f7b 00000000004149bf
writing vis file to ../DRAMSim2/results/MARSS/DDR3_micron_8M_8B_x16_sg15/1GB.1Ch.2R.scheme2.open_page.32TQ.32CQ.RtB.pRank.vis
DRAMSim2 Clock Frequency =666666666Hz, CPU Clock Frequency=2000000000Hz
WARNING: address 0x3a4eb9bf is not aligned to the request size of 64
WARNING: address 0x3a4eb9bf is not aligned to the request size of 64
WARNING: address 0x3b0b1ff8 is not aligned to the request size of 64
WARNING: address 0x3b0b1ff8 is not aligned to the request size of 64
WARNING: address 0x3a4eb9bf is not aligned to the request size of 64
...
PTLCALL type PTLCALL_ENQUEUE
MARSSx86::Command received : -stop

My short program produces around one hundred of these warnings. In this case with the private_L2 machine (specified in marss.dramsim/config/default.conf), the simulation still runs to completion despite these warnings; however, with other machine configurations, I have received "Segmentation fault (core dumped)" or "[ERROR (MemoryController.cpp:471)]: == Error - Command Bus Collision" after the warning messages, and the emulator dies.

I tried setting either/both of "ADDRESS_MAPPING_SCHEME=scheme7" and "NUM_CHANS=2" in my DRAMSim2/system.ini file, but these did not eliminate the warnings. When I change my simconfig file (marss.dramsim/test.cfg) to specify "-machine shared_l2" instead of the private_L2 machine, the warnings do not appear. This suggests that there is maybe some misconfiguration between the caches and the memory module, but I've been unable to figure out the problem (and I was surprised that it happened with the default example private_L2 machine).

I can provide the Marss .conf files or any other information that may be needed. Thanks for sharing the DRAMSim2 tool with the community.

[dhconly]

Since we're assuming that a request is for BL_BUS_WIDTH (8×64 bit), the bottom 6 bits of this address *should_ be all zeros if it's not, issue a warning

[dramninjasUMD]

I've actually removed this warning in a recent commit. The issue is that a real memory controller would be able to deal with sub-cache line/non cache aligned accesses which may come from a non-cache source (for example, a DMA controller). However, since we are not storing data, the procedure would require all of the data to be fetched and potentially masked before being sent back (though I'd have to think about the case of a small write -- we may have to read the whole cache line from DRAM, update a portion of it, and then send the whole cache line back?).

However, at the moment, if we assume the behavior is identical, the warning is more trouble than its worth (since it scares users). At some point I added some code to marss.dramsim to force alignment to get around this warning, but that just seems silly to go out of my way to bypass my own warning message.