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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
