Sounds good. I am working on it. Thanks, Amin
On Wed, Jun 19, 2013 at 9:26 PM, Andreas Hansson <[email protected]>wrote: > Hi Amin, > > Rather than doing that I would suggest to have a burst length in beats > for each memory type. That in combination with its interface width enables > it to determine for each request it sees how to chop it up. As mentioned > earlier, this requires the memory controller model to be extended to reason > about "system" packets vs "dram" packets and assemble the responses > properly. > > Andreas > > From: Amin Farmahini <[email protected]> > Date: Wednesday, 19 June 2013 15:48 > To: gem5 Developer List <[email protected]>, Andreas Hansson < > [email protected]> > > Subject: Re: [gem5-dev] Review Request 1927: mem: replacing > bytesPerCacheLine with DRAM burstLength in SimpleDRAM > > Hi Andreas, > > I have one more question for you. tBRUST in all DRAM configurations in > gem5 is based on 64-byte cache lines. Some DRAM configurations such as > LPDDR2_S4_1066_x32 has a x32 interface and a burst length of 8 (8 beats per > burst). So in these configurations, two BL8 are needed for a 64-byte memory > request. To account for that, I am adding a new parameter called > bursts_per_request. So, for LPDDR2_S4_1066_x32, bursts_per_request is 2, > while for DDR3_1600_x64, bursts_per_request is 1. Would you let me know > your thoughts on this? Shall I go ahead? > > PS: As we discussed earlier, I plan to add parameters such as bus_width in > bits and burst_lenght in beats to my new patch. > > Thanks, > Amin > > > On Wed, Jun 19, 2013 at 12:03 PM, Ali Saidi <[email protected]> wrote: > >> >> >> Since we don't support (to my knowledge) different caches with >> different cache line sizes in the same system, perhaps it does make >> sense to make it a parameter on the system level. I don't think it >> should be a compiled constant however. >> >> Ali >> >> On 19.06.2013 11:40, >> Andreas Hansson wrote: >> >> > Hi Amin, >> > >> > I think there are two things >> here: >> > >> > 1. don't use the cache line size as a "unit" in the DRAM >> model. We agree on this and your patch is a good start. >> > 2. Should we >> drop peerBlockSize and put a cache line size parameter (or even >> compile-time constant?) at the system level? >> > >> > Andreas >> > >> > From: >> Amin Farmahini <[email protected]<mailto:[email protected]>> >> > Date: >> Wednesday, 19 June 2013 11:30 >> > To: Andreas Hansson >> <[email protected]<mailto:[email protected]>> >> > Cc: Nilay >> Vaish <[email protected]<mailto:[email protected]>>, gem5 Developer List >> <[email protected]<mailto:[email protected]>> >> > Subject: Re: [gem5-dev] >> Review Request 1927: mem: replacing bytesPerCacheLine with DRAM >> burstLength in SimpleDRAM >> > >> > I agree with dropping peerBlockSize. >> > >> For now, we only support cache line size of 64 (32-byte lines are also >> supported, but in terms of timing they are treated as 64-byte cache >> lines). >> > I don't like the idea of a cache line size parameter to the >> system. We should make DRAM model independent of cache line size. DRAM >> should not care what the cache line size is. DRAM controller deals with >> the memory request size, not the cache line size. Most SoCs are >> connected to devices with different cache line sizes. >> > If the request >> size is the same as dram burst size, then we are fine. If it is larger, >> then we panic. In the future, we can support splitting requests larger >> than 64 bytes. >> > [https://mail.google.com/mail/u/0/images/cleardot.gif >> [3]] >> > Forgot to send it to the group. >> > >> > Amin >> > >> > On Wed, Jun 19, >> 2013 at 11:18 AM, Andreas Hansson >> <[email protected]<mailto:[email protected]>> wrote: >> > On >> that note I'd suggest we completely drop the peerBlockSize and the >> > >> "impression" that we can have different cache line size at different >> parts >> > in the system. We could add a cache line size parameter to the >> system. >> > >> > Thoughts? >> > >> > Andreas >> > >> > On 19/06/2013 11:14, "Nilay >> Vaish" <[email protected]<mailto:[email protected]>> wrote: >> > >> >> On >> Wed, 19 Jun 2013, Andreas Hansson wrote: >> >> >> >>> >> ----------------------------------------------------------- This is an >> automatically generated e-mail. To reply, visit: >> http://reviews.gem5.org/r/1927/#review4448 [1] >> ----------------------------------------------------------- >> src/mem/SimpleDRAM.py <http://reviews.gem5.org/r/1927/#comment4174 [2]> >> Hi Nilay, You cannot compute this from params as the cache line size is >> determined in the C++ code. >> >> This means that you are assuming what the >> cache line size is. In that case, I would rather have the cache line >> size as a param. -- Nilay >> > >> > -- 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. >> > >> > -- 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. >> > >> _______________________________________________ >> > gem5-dev mailing >> list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/gem5-dev >> [4] >> >> >> >> Links: >> ------ >> [1] http://reviews.gem5.org/r/1927/#review4448 >> [2] >> http://reviews.gem5.org/r/1927/#comment4174 >> [3] >> https://mail.google.com/mail/u/0/images/cleardot.gif >> [4] >> http://m5sim.org/mailman/listinfo/gem5-dev >> _______________________________________________ >> 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. > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
