HI Amin,
It would definately be good to add this functionality, but I think tha the multi-ported cache aspect has to be part of the change. Thanks, Ali On 29.08.2012 13:50, Andreas Hansson wrote: > Hi Amin, > > From my point of view it sounds like a good idea to restrict the cache to one packet per cycle (or even have a port width and then use the clock to only allow x bytes per cycle). > > The only drawback I can see is that some people might use the higher speed to mimic a multi-ported cache. We could always solve that by actually adding more ports to the cache if someone really wants to keep this option. > > Andreas > > From: Amin Farmahini <aminfar@gmail.comamin...@gmail.com>> > Reply-To: gem5 users mailing list <gem5-users@gem5.orggem5-us...@gem5.org>> > Date: Wednesday, 29 August 2012 11:46 > To: gem5 users mailing list <gem5-users@gem5.orggem5-us...@gem5.org>> > Subject: Re: [gem5-users] timing access model for dcache ports > > I did the same experiment with O3CPU and I am seeing that the LSQ can receive multiple packets per cpu cycle. For example, the trace below shows that it gets 8 packets in one cycle: > > 7864000: system.cpu0.iew.lsq: received pkt for addr:0x67f80 > 7864001: system.cpu0.iew.lsq: received pkt for addr:0x67f88 > 7864002: system.cpu0.iew.lsq: received pkt for addr:0x67f84 > 7864003: system.cpu0.iew.lsq: received pkt for addr:0x67f90 > 7864004: system.cpu0.iew.lsq: received pkt for addr:0x67f8c > 7864005: system.cpu0.iew.lsq: received pkt for addr:0x67f98 > 7864006: system.cpu0.iew.lsq: received pkt for addr:0x67fa0 > 7864007: system.cpu0.iew.lsq: received pkt for addr:0x67f9c > > As I mentioned in previous posts, it does not make sense that LSQ can accept up to 8 response packets at a time. Unless I am overlooking something, I believe that there should be a limit on the number of RESPONSE packets that cpu can receive from cache (As Ali mentioned, there is already a mechanism in O3CPU to limit number of REQUEST packets). Before trying to fix this, I just wanted to make sure this is also considered a bug by others. > > cpu: O3CPU at 1GHz, L1 latency: 2ns, LSQ size: 16, ISA: ARM > > Thanks, > Amin > > On Wed, Jun 13, 2012 at 10:00 PM, Nilay Vaish <ni...@cs.wisc.eduni...@cs.wisc.edu>> wrote: > Amin, you might be correct here. Why don't you investigate this further, and if you think gem5 should support this, then you can submit a patch which adds this support to caches. > > -- > Nilay > > Tue, 12 Jun 2012, Amin Farmahini wrote: > Ali, > > That's right. O3 limits the number of requests, but even in this case, > responses can return to O3 in the same cycle. > My cpu also limits the number of requests. My cpu sends only one request > per cpu cycle. My question is about responses from cache. I would like to > know why the l1 cache sends multiple responses to cpu in the same cycle > (although in consecutive ticks)? For example, my cpu sends individual > requests in cycles 1, 2, and 3, and receives three responses in cycle 10. > Basically this is what is happening in the log file. > My conclusion would be that cache does not limit the number of responses > back to cpu and this mechanism (limiting responses) should be provided in > cpu. > > Thanks, > Amin > > On Tue, Jun 12, 2012 at 9:41 PM, Ali Saidi <saidi@umich.edusa...@umich.edu>> wrote: > > ** > > The O3 CPU counts the number of requests it's submitted and limits it to > the number set. I'm not sure how you got the trace you posted, but in our > model it's the CPU's responsibility to limit the number of requests to the > cache. > > Ali > > On 12.06.2012 15:40, Amin Farmahini wrote: > > I only modified the code in cpu side and not the cache. And > CPU::DcachePort::recvTiming() is called when the l1 cache has made a > response packet ready. I would guess the same behavior can be seen in O3 > cpu, because what I am doing is similar to LSQ implementation in O3. > I totally agree that this should be decided by L1 cache bandwidth, but I > don't know if this bandwidth is modeled in Gem5. > BTW, I am using classic model, and not Ruby. > > Thanks, > Amin > > On Tue, Jun 12, 2012 at 3:24 PM, Nilay <ni...@cs.wisc.eduni...@cs.wisc.edu>> wrote: > > at physically such a design would not make any sense (may be only for > now). But this should be decided by the bandwidth of the L1 cache and of > the link between the CPU the L1 cache. > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.orggem5-us...@gem5.org> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.orggem5-us...@gem5.org> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > -- 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@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
