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]<mailto:[email protected]>> Date: Wednesday, 19 June 2013 15:48 To: gem5 Developer List <[email protected]<mailto:[email protected]>>, Andreas Hansson <[email protected]<mailto:[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]<mailto:[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]><mailto:[email protected]<mailto:[email protected]>>> > Date: Wednesday, 19 June 2013 11:30 > To: Andreas Hansson <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> > Cc: Nilay Vaish <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>>, gem5 Developer List <[email protected]<mailto:[email protected]><mailto:[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]><mailto:[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]><mailto:[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]<mailto:[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]<mailto:[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
