> On June 17, 2013, 11:39 a.m., Nilay Vaish wrote: > > src/mem/SimpleDRAM.py, line 121 > > <http://reviews.gem5.org/r/1927/diff/1/?file=36224#file36224line121> > > > > Is 'burst length' a standard term for those who dabble with drams? May > > be the > > comment can be expanded to explain what is meant by a burst.
Yes, it is. > On June 17, 2013, 11:39 a.m., Nilay Vaish wrote: > > src/mem/SimpleDRAM.py, line 185 > > <http://reviews.gem5.org/r/1927/diff/1/?file=36224#file36224line185> > > > > Ok, I am confused here. What is the difference between a dram page and > > a > > row buffer? It seems to me that you are assuming something more than > > what > > has been stated here as 128 * 64 != 1024. as far as I know, row and page are usually used the same way. I am saying usually, because some people tend to use differently. Andreas may correct me. 1kB per module. since this is 8x8, so the rowbuffer is 8k per entire DRAM. > On June 17, 2013, 11:39 a.m., Nilay Vaish wrote: > > src/mem/SimpleDRAM.py, line 198 > > <http://reviews.gem5.org/r/1927/diff/1/?file=36224#file36224line198> > > > > Assuming BL stands for burst length, can you explain why do we need > > this > > to be fixed to 5ns and not make it a function of the burst length? > > Secondly, why is this not a function of the clock frequency? DDR3 supports only BL8. DDR2 supports both BL4 and BL8. so tBURST is fixed for DDR3. well, it is a function of freq, 1.25*ns4=5ns. note that burst length is always 8 for DDR3. I did not change it, because right now DRAM parameters are not defined to be a function of DRAM internal freq and DRAM bus frequency. > On June 17, 2013, 11:39 a.m., Nilay Vaish wrote: > > src/mem/SimpleDRAM.py, line 225 > > <http://reviews.gem5.org/r/1927/diff/1/?file=36224#file36224line225> > > > > Now I am confident that some thing is wrong either with the comment > > here or the one in DDR3's definition. not wrong. this is a 1x32 configuration, so there is only one module. so 16*64=1kB. Up there, there were 8 modules. > On June 17, 2013, 11:39 a.m., Nilay Vaish wrote: > > src/mem/simple_dram.cc, line 103 > > <http://reviews.gem5.org/r/1927/diff/1/?file=36226#file36226line103> > > > > Typo in length. Actually, I was not aware that you can write comments > > after the if() statement without using braces. we'll fixit. > On June 17, 2013, 11:39 a.m., Nilay Vaish wrote: > > src/mem/simple_dram.cc, line 1093 > > <http://reviews.gem5.org/r/1927/diff/1/?file=36226#file36226line1093> > > > > Looking at how it is incremented, this was really shady. yeah, actually I did not think that was correct (or at least it could be wrong in many cases). so I removed it. - Amin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1927/#review4440 ----------------------------------------------------------- On June 17, 2013, 4:13 a.m., Amin Farmahini wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1927/ > ----------------------------------------------------------- > > (Updated June 17, 2013, 4:13 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > This patch gets rid of bytesPerCacheLine parameter and makes the DRAM > configuration separate from cache line size. > Instead of bytesPerCacheLine, I define a parameter for DRAM called > burst_length. The burst_length parameter shows the size of a DRAM burst in > bytes and is 64 bytes for all current DRAM configurations. Note, this > parameter is coupled with tBURST. > Also, I replace lines_per_rowbuffer with bursts_per_rowbuffer, because > lines_per_rowbuffer is defined based on 64-byte cache lines which makes the > code unportable. > > Next patch could be to add support for requests larger than burst length. > > > Diffs > ----- > > src/mem/SimpleDRAM.py UNKNOWN > src/mem/simple_dram.hh UNKNOWN > src/mem/simple_dram.cc UNKNOWN > > Diff: http://reviews.gem5.org/r/1927/diff/ > > > Testing > ------- > > None > > > Thanks, > > Amin Farmahini > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
