On Mon, June 11, 2012 2:37 pm, Amin Farmahini wrote: > Hi, > > I am doing some analysis with the Timing access model for dcache ports and > I am seeing weird behavior that does not make sense to me. Similar to the > DcachePort class in Timing and O3 cpus, I have a > CPU::DcachePort::recvTiming() function that processes timing packets > received by DcachePort in cpu side. I found out that in one cycle (but in > consecutive ticks), the recvTiming() is called three times which means > three packets are received by the DcachePort defined in cpu side. Below is > a piece of the log file showing this behavior: > > 13743000: system.cpu1-dport: Received response for Addr 0x67c28 from > Dcache > 13743000: system.cpu1.dcache-cpu_side_port-queue.wrapped_event: > EventWrapped event scheduled @ 13743001 > 13743001: system.cpu1-dport: Received response for Addr 0x67c2c from > Dcache > 13743001: system.cpu1.dcache-cpu_side_port-queue.wrapped_event: > EventWrapped event scheduled @ 13743002 > 13743002: system.cpu1-dport: Received response for Addr 0x67c30 from > Dcache > 13743002: system.cpu1-dport.wrapped_event: EventWrapped event scheduled @ > 13743500 > > I thought the l1 cache can only respond one packet each cache cycle, but > now I am seeing that many packets could be responded by the l1 cache in > the > same cycle (even though those packets are initially sent to the cache in > different cycles). Is that expected? > If so, I think this is cpu's job to limit the number of packets processed > each cycle and schedule a retry event or something. Is it right? > > ISA: ARM, cpu frequency: 2GHz, l1 latency: 1ns, l1 block size: 64, l1 > assoc: 1, l1 mshr: 10
Why should the L1 cache respond to only packet in a cycle? It might be that 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. In any case, it seems you have modified the code. If that's true, then making any conclusions about gem5's behaviour from above trace would not be correct. -- Nilay _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
