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> 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> 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> 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 >>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<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<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
