Thanks Tao for your response. That clarifies a lot of my questions. So here is what I understand:
DRAM module runs at a particular clock frequency. Bus connecting DRAM module and PHY runs in sync with this clock frequency. PHY as well runs synchronously to DRAM module clock frequency. Now, for a 64bit bus, burst length of 8 (64 bytes transferred per burst) my understanding of read operations is that, after the read command is issued, first bit of data is available after read latency. At immediate clock edge after read latency, 8bytes are sampled and transferred over the bus. Then every consecutive rising and falling clock edges, 8 more bytes are sampled and transferred over the bus for four consecutive clock cycles. Thereby, PHY receives all 64bytes worth data at the end of read latency + 4 clock cycles. Is this right? Also, any idea if this bus (connecting DRAM and PHY) same as system bus? For example, is it AMBA/AHB on latest ARM SoCs? Thanks again, -Rizwana On Thu, Jan 22, 2015 at 12:49 PM, Tao Zhang <tao.zhang.0...@gmail.com> wrote: > Hi Rizwana, > > see my understanding inline. Thanks, > > -Tao > > On Thu, Jan 22, 2015 at 8:12 AM, Rizwana Begum via gem5-users < > gem5-users@gem5.org> wrote: > >> Hello Andreas, >> >> Thanks for the reply. Sure, I will try to get the patch up on review >> board. >> I have another question: Though this is related to DDR/MC architecture >> and not directly related to Gem5 DDR model implementation, I am hoping you >> (or anyone else on the list) would have a good understanding to clarify my >> confusions: >> >> As far as I understand 'busBusyUntil' represents the data bus. This >> variable is used to keep track of data bus availability: >> >> 1. Is the data bus is the bus used to transfer data from core DRAM module >> to PHY? >> > > Yes, you are right. In addition, this is also the bus to transfer data > from PHY to DRAM module. > > >> 2. I believe PHY is the DRAM physical interface IP. Where is it >> physically located? Is it located on core along side memory controller (MC) >> or on DIMMs? And what exactly does physical bus (the wires connecting DIMMs >> to MC) connect? DRAM and PHY or PHY and MC? >> > > It is on the core/MC side. The physical bus refers to DRAM and PHY. > Logically, you can treat PHY as a part of MC and it just incurs some extra > latency. In this way, the physical bus can be extended to DRAM and MC. > > >> 3. My confusion is that actual physical bus on SoC connecting the DRAM >> module and MC should be different from data bus that 'busBusyUntil' is >> representing. It takes tBURST ns (function of memory cycles) to transfer >> one burst on the data bus and the actual physical bus speed shouldn't be >> depending upon memory frequency for transferring data from DRAM to MC. Am I >> right? >> > > The "busBusyUntil" is still valid. The actual physical bus speed > should be consistent with the SPEC (e.g., 800MHz, 933MHz, 1600MHz...). > Remember, the JEDEC DRAM is a Synchronous DRAM. It means both PHY and DRAM > module should be in sync with the same clock frequency. As one end of the > connection is the DRAM module, PHY should run at the same frequency as DRAM > module runs. > > >> I would appreciate if anyone can provide insight into these questions. >> >> Thank you, >> -Rizwana >> >> >> >> >> On Wed, Jan 21, 2015 at 4:45 PM, Andreas Hansson <andreas.hans...@arm.com >> > wrote: >> >>> Hi Rizwana, >>> >>> It could very well be that you’ve hit a bug. I’d suggest to post a >>> review on the reviewboard to make it more clear what changes need to be >>> done. If you’re not familiar with the process have a look at >>> http://www.gem5.org/Commit_Access. The easiest is to use the >>> reviewboard mercurial plugin. >>> >>> I look forward to see the patch. >>> >>> Thanks, >>> >>> Andreas >>> >>> From: Rizwana Begum via gem5-users <gem5-users@gem5.org> >>> Reply-To: Rizwana Begum <rizwana....@gmail.com>, gem5 users mailing >>> list <gem5-users@gem5.org> >>> Date: Wednesday, 21 January 2015 16:24 >>> To: gem5 users mailing list <gem5-users@gem5.org> >>> Subject: [gem5-users] DRAM controller write requests merge >>> >>> Hello Users, >>> >>> I am trying to understanding write packets queuing in DRAM controller >>> model. I am looking at 'addToWriteQueue' function. From my understanding so >>> far, it merges write requests across burst boundaries. Looking at following >>> if statement: >>> >>> if ((addr + size) >= (*w)->addr && >>> ((*w)->addr + (*w)->size - addr) <= >>> burstSize) { >>> // the new one is just before or partially >>> // overlapping with the existing one, and together >>> // they fit within a burst >>> .... >>> .... >>> .... >>> } >>> >>> Merging here may make the write request go across burst boundary. Size >>> computation in the beginning of the for loop of this function suggests that >>> packets are split at burst boundaries. For example, if the packet addr is >>> 16, burst size is 32 bytes and packet request size is 25 bytes (all in >>> decimal for ease), then 2 write bursts should be added to the queue: 16-31, >>> 32-40. However, while merging, lets say if there existed a packet already >>> in write queue from 32-40, then a write from 16-40 is added to the queue >>> which is across burst boundary. is that physically possible? Shouldn't >>> there be two write requests in the queue:16-31, 32-40 instead of one single >>> merged request? >>> >>> Thank you, >>> -Rizwana >>> >>> >>> >>> -- 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. >>> >>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>> Registered in England & Wales, Company No: 2557590 >>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>> 9NJ, Registered in England & Wales, Company No: 2548782 >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
