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.
Forgot to send it to the group. Amin On Wed, Jun 19, 2013 at 11:18 AM, Andreas Hansson <andreas.hans...@arm.com>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" <ni...@cs.wisc.edu> 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 > >> ----------------------------------------------------------- > >> > >> > >> > >> src/mem/SimpleDRAM.py > >> <http://reviews.gem5.org/r/1927/#comment4174> > >> > >> 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. > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
