Hi Andreas,
Sure thing. We try to closely replicate the parameters used in GPGPU-Sim
v3.2.2, which are specified in the Hynix datasheet here:
http://www.hynix.com/datasheet/pdf/graphics/H5GQ1H24AFR(Rev1.0).pdf.
Here are relevant excerpts from the GPGPU-Sim GTX480 config file
(attached):
# The DRAM return queue and the scheduler queue together should provide
buffer
# to sustain the memory level parallelism to tolerate DRAM latency
# To allow 100% DRAM utility, there should at least be enough buffer to
sustain
# the minimum DRAM latency (100 core cycles). I.e.
# Total buffer space required = 100 x 924MHz / 700MHz = 132
-gpgpu_frfcfs_dram_sched_queue_size 16
-gpgpu_dram_return_queue_size 116
-dram_data_command_freq_ratio 4 # GDDR5 is QDR
-gpgpu_dram_timing_opt "nbk=16:CCD=2:RRD=6:RCD=12:RAS=28:RP=12:RC=40:
CL=12:WL=4:CDLR=5:WR=12:nbkgrp=4:CCDL=3:RTPL=2"
If anything needs clarification, I'm happy to help sort it out. Just let
me know.
Thanks!
Joel
On Mon, Oct 13, 2014 at 4:11 PM, Andreas Hansson via gem5-dev <
[email protected]> wrote:
> Hi Joel,
>
> I am happy to spend the 5 minutes creating a GDDR5 configuration. Do you
> have any specific data sheet you would like to capture?
>
> Andreas
>
> On 10/13/14, 10:09 PM, "Joel Hestness via gem5-dev" <[email protected]>
> wrote:
>
> >Hi guys,
> >
> >
> >> Thanks for the clarification. I believe the RubyMemoryController is
> >> completely Pareto dominated by the vanilla DRAMCtrl module, but if there
> >> is any specific feature/setting missing I would be keen to know.
> >>
> >> If possible I would like to make sure we use the same controller as a
> >> default for all timing simulations (even if the other one would be
> >> maintained as a fallback).
> >
> >
> >I'd like to second the desire to have a simple replacement baseline that
> >performs at least as well as the RubyMemoryController in most/all cases:
> >gem5-gpu now has more than 100 users, and as far as I know, we are all
> >using Ruby and thus the RubyMemoryController. The RubyMemoryController is
> >pretty simple to configure similarly to DDR3 or GDDR5 and to interpret
> >results. It performs surprisingly close to some GPU hardware. If this
> >controller goes away, I (and I'm sure other gem5-gpu users) would prefer
> >to
> >have something that is known to perform as well and is also easy to
> >configure.
> >
> >I think we (the gem5-gpu crew) are fine with the RubyMemoryController
> >going
> >away eventually. However, given that there isn't currently a GDDR-like
> >DRAMCtrl configuration in gem5, I'd like to second Nilay and Brad that we
> >offer users sufficient time to prepare for RubyMemoryController removal.
> >We
> >will need to adapt our heterogeneous Ruby coherence protocols, and other
> >users have their own protocols they'd need to adapt as well.
> >
> >
> > Joel
> >
> >
> >
> >
> >
> >> On 10/13/14, 9:01 PM, "Nilay Vaish via gem5-dev" <[email protected]>
> >> wrote:
> >>
> >> >On Mon, 13 Oct 2014, Andreas Hansson via gem5-dev wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> With Nilay?s recent improvements to Ruby I would like to understand
> >>if
> >> >> there is any point in still having the RubyMemoryControl, or if we
> >> >> should just clean things up a bit and remove it. I would think the
> >>best
> >> >> way forward is to clean up the integration of Ruby and classic and
> >> >> ensure that there is no duplicated functionality beyond what is
> >> >>strictly
> >> >> necessary.
> >> >>
> >> >> Nilay, do you think this would make sense? Is there anyone else with
> >> >>any
> >> >> opinions in this matter?
> >> >>
> >> >
> >> >
> >> >I was in favor of dropping RubyMemoryControl. But I had some
> >>discussion
> >> >with Brad Beckmann from AMD. Since AMD has some infrastructure in
> >>place
> >> >already, they would like to retain RubyMemoryControl for the time
> >>being.
> >> >
> >> >I suggest that we retain the memory controller code in ruby for another
> >> >six months or so, and then we will drop it. In the mean time, we
> >> >will update the interface so that ruby protocols can use classic memory
> >> >controller. The code for this is already on the reviewboard. Over
> >>this
> >> >six month period, I hope, most users would have switched to using
> >>classic
> >> >controller.
> >> >
> >> >Thanks
> >> >Nilay
> >> >_______________________________________________
> >> >gem5-dev mailing list
> >> >[email protected]
> >> >http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> >>
> >> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> >> confidential and may also be privileged. If you are not the intended
> >> recipient, please notify the sender immediately and do not disclose the
> >> contents to any other person, use it for any purpose, or store or copy
> >>the
> >> information in any medium. Thank you.
> >>
> >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> >> Registered in England & Wales, Company No: 2557590
> >> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
> >>9NJ,
> >> Registered in England & Wales, Company No: 2548782
> >> _______________________________________________
> >> gem5-dev mailing list
> >> [email protected]
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> >
> >
> >
> >--
> > Joel Hestness
> > PhD Student, Computer Architecture
> > Dept. of Computer Science, University of Wisconsin - Madison
> > http://pages.cs.wisc.edu/~hestness/
> >_______________________________________________
> >gem5-dev mailing list
> >[email protected]
> >http://m5sim.org/mailman/listinfo/gem5-dev
> >
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No: 2548782
>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
>
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://pages.cs.wisc.edu/~hestness/
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
