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