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 <amin...@gmail.com<mailto:amin...@gmail.com>> Reply-To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Date: Wednesday, 29 August 2012 11:46 To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@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.edu<mailto:ni...@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 <sa...@umich.edu<mailto:sa...@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.edu<mailto:ni...@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.org<mailto:gem5-users@gem5.org> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list gem5-users@gem5.org<mailto:gem5-users@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
