Hi guys,
What Jason was referring to is that Ruby has it's own memory controller (gem5/src/mem/ruby/system/RubyMemoryControl.*), which models somewhat abstracted DRAM timings in the controller. It uses a gem5 SimpleMemory as its backing store and ignores the timings in that object rather than using something like gem5's SimpleDRAM, which has timings built in (both of these classes are defined in gem5/src/mem/). Note that the SimpleDRAM is often used with the gem5 classic memory model (i.e. not Ruby memory model) to get DRAM timings. The Ruby memory controller can actually be quite accurate in spite of the abstract timings, though it is limited to modeling a closed-page row buffer precharge policy.
To model something like GDDR5, you can set the parameters of the Ruby memory controller that is instantiated in gem5-gpu configs. The command line parameters and controller settings for this are defined in gem5-gpu/configs/GPUMemConfig.py, and include the total controller latency (e.g. scheduling delay), memory bus frequency, the number of cycles for a bus transfer (e.g. 64B cache line / 32-bit bus / DDR = 8 cycles), and the bank busy time (CL+tRP+tRCD+CAS). For GDDR5, you'd want to add the prefetch buffering latency to the total memory controller latency.
Your other option would require adding a new memory controller in Ruby to wrap gem5's SimpleDRAM (or analogously, the appropriate component in DRAMSim2 if you're using those patches). This new controller would need to be able to receive Ruby messages from directory controllers (e.g. gem5-gpu/src/mem/protocol/VI_hammer-dir.sm), and convert those to packets to be sent to the SimpleDRAM. On return, it would have to convert response packets back to Ruby messages for return to the directory. On brief inspection, I think this would be a fair amount of work.
Hope this helps,
Joel