Hi All, 1. In the SimpleDRAM controller, it is assumed that the DRAM burst size equals to the cache line size. I think it makes more sense to use a separate variable for burst size and get rid of bytesPerCacheLine. The reason is that the DRAM controller could be connected (through a bus) to caches with different cache line sizes (e.g., a coherent cache, and a non-coherent cache/SPM for stream peripherals with large line sizes). 2. The other thing I noticed is that lines_per_rowbuffer (in SimpleDRAM.py) is set based on 64-byte cache lines. This makes the code unportable in case other cache line sizes are used. Why not using bytes per rowbuffer instead? Thanks, Amin

Hi Amin, Your two suggestions definitely make sense, and we are heading in that direction. The main reasons for not doing that at the moment was simplicity. The DRAM model currently does support splitting two cache lines into DRAM accesses. Hence, by expressing burst and page size in units of the cache line size we avoid "illegal" configurations. I hope that both brings some answers as to why it looks the way it does. If you want to take a stab at addressing the issues go ahead and submit a patch to the review board. Thanks, Andreas From: Amin Farmahini <aminfar(a)gmail.com<mailto:aminfar(a)gmail.com>> Reply-To: gem5 users mailing list <gem5-users(a)gem5.org<mailto:gem5-users(a)gem5.org>> Date: Friday, 7 June 2013 21:54 To: gem5 users mailing list <gem5-users(a)gem5.org<mailto:gem5-users(a)gem5.org>> Subject: [gem5-users] Some notes about SimpleDRAM controller Hi All, 1. In the SimpleDRAM controller, it is assumed that the DRAM burst size equals to the cache line size. I think it makes more sense to use a separate variable for burst size and get rid of bytesPerCacheLine. The reason is that the DRAM controller could be connected (through a bus) to caches with different cache line sizes (e.g., a coherent cache, and a non-coherent cache/SPM for stream peripherals with large line sizes). 2. The other thing I noticed is that lines_per_rowbuffer (in SimpleDRAM.py) is set based on 64-byte cache lines. This makes the code unportable in case other cache line sizes are used. Why not using bytes per rowbuffer instead? Thanks, Amin -- 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.

Thanks for the response Andreas. I am willing to work on a patch and submit it, if it can be done fairly easily considering my small knowledge of DRAM :). So if I understand you right, in order to apply these suggestions, the SimpleDRAM controller should be able to split requests that are larger than 64 bytes to multiple DRAM transactions. I think this is also the case for current DDR3 controllers when an 8x8 configuration is used (since each DRAM burst returns 64 bytes in this configuration). For example, if the request size from cache (or any other units) is 128 bytes, then the request should be split into two 64-byte transactions. The DRAM controller also should be able to make a single 128-byte response. Please let me know if my interpretation of your response is right. Thanks, Amin On Mon, Jun 10, 2013 at 1:35 AM, Andreas Hansson <Andreas.Hansson(a)arm.com>wrote: > Hi Amin, > > Your two suggestions definitely make sense, and we are heading in that > direction. > > The main reasons for not doing that at the moment was simplicity. The > DRAM model currently does support splitting two cache lines into DRAM > accesses. Hence, by expressing burst and page size in units of the cache > line size we avoid "illegal" configurations. I hope that both brings some > answers as to why it looks the way it does. > > If you want to take a stab at addressing the issues go ahead and submit > a patch to the review board. > > Thanks, > > Andreas > > From: Amin Farmahini <aminfar(a)gmail.com> > Reply-To: gem5 users mailing list <gem5-users(a)gem5.org> > Date: Friday, 7 June 2013 21:54 > To: gem5 users mailing list <gem5-users(a)gem5.org> > Subject: [gem5-users] Some notes about SimpleDRAM controller > > Hi All, > > 1. In the SimpleDRAM controller, it is assumed that the DRAM burst size > equals to the cache line size. I think it makes more sense to use a > separate variable for burst size and get rid of bytesPerCacheLine. The > reason is that the DRAM controller could be connected (through a bus) to > caches with different cache line sizes (e.g., a coherent cache, and a > non-coherent cache/SPM for stream peripherals with large line sizes). > > 2. The other thing I noticed is that lines_per_rowbuffer (in > SimpleDRAM.py) is set based on 64-byte cache lines. This makes the code > unportable in case other cache line sizes are used. Why not using bytes per > rowbuffer instead? > > Thanks, > Amin > > -- 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-users mailing list > gem5-users(a)gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >

Andreas, I just submitted a patch regarding this email. Please go over it. http://reviews.gem5.org/r/1927/ Thanks, Amin On Mon, Jun 10, 2013 at 11:46 PM, Amin Farmahini <aminfar(a)gmail.com> wrote: > Thanks for the response Andreas. I am willing to work on a patch and > submit it, if it can be done fairly easily considering my small knowledge > of DRAM :). > > So if I understand you right, in order to apply these suggestions, the > SimpleDRAM controller should be able to split requests that are larger than > 64 bytes to multiple DRAM transactions. I think this is also the case for > current DDR3 controllers when an 8x8 configuration is used (since each DRAM > burst returns 64 bytes in this configuration). For example, if the request > size from cache (or any other units) is 128 bytes, then the request should > be split into two 64-byte transactions. The DRAM controller also should be > able to make a single 128-byte response. > > Please let me know if my interpretation of your response is right. > > Thanks, > Amin > > > On Mon, Jun 10, 2013 at 1:35 AM, Andreas Hansson <Andreas.Hansson(a)arm.com>wrote: > >> Hi Amin, >> >> Your two suggestions definitely make sense, and we are heading in that >> direction. >> >> The main reasons for not doing that at the moment was simplicity. The >> DRAM model currently does support splitting two cache lines into DRAM >> accesses. Hence, by expressing burst and page size in units of the cache >> line size we avoid "illegal" configurations. I hope that both brings some >> answers as to why it looks the way it does. >> >> If you want to take a stab at addressing the issues go ahead and submit >> a patch to the review board. >> >> Thanks, >> >> Andreas >> >> From: Amin Farmahini <aminfar(a)gmail.com> >> Reply-To: gem5 users mailing list <gem5-users(a)gem5.org> >> Date: Friday, 7 June 2013 21:54 >> To: gem5 users mailing list <gem5-users(a)gem5.org> >> Subject: [gem5-users] Some notes about SimpleDRAM controller >> >> Hi All, >> >> 1. In the SimpleDRAM controller, it is assumed that the DRAM burst size >> equals to the cache line size. I think it makes more sense to use a >> separate variable for burst size and get rid of bytesPerCacheLine. The >> reason is that the DRAM controller could be connected (through a bus) to >> caches with different cache line sizes (e.g., a coherent cache, and a >> non-coherent cache/SPM for stream peripherals with large line sizes). >> >> 2. The other thing I noticed is that lines_per_rowbuffer (in >> SimpleDRAM.py) is set based on 64-byte cache lines. This makes the code >> unportable in case other cache line sizes are used. Why not using bytes per >> rowbuffer instead? >> >> Thanks, >> Amin >> >> -- 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-users mailing list >> gem5-users(a)gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >