Hi Prakhar, I would be cautious with interpreting these packets as gem5 is recycling them in certain cases. I think what has happened here is that a write request was responded to the minute the write was added to the memory controller queue, that response was returned to the master that sent it (note that the DRAM request is still in the queue, with the original packet pointer that went from WriteRequest to WriteResponse). The master of the original packet now reuses that same packet and re-initialises it as a read and sends it out again.
This happens because the DRAM queue really is not concerned with the original packets. It has the pointers, but they point to irrelevant objects. Makes sense? Andreas From: gem5-users <gem5-users-boun...@gem5.org<mailto:gem5-users-boun...@gem5.org>> on behalf of Prakhar Javre <prakharj2...@gmail.com<mailto:prakharj2...@gmail.com>> Reply-To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Date: Thursday, 19 October 2017 at 20:24 To: "gem5-users@gem5.org<mailto:gem5-users@gem5.org>" <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] Observing ReadReq in writeQueue Hey guys, Could you please help me understand why writeQueue is having ReadReq packets in it. Debug statements - ===WRITE QUEUE=== 2559455250: system.mem_ctrls: Write 10632576, command: ReadExReq, ContextId: 1, MasterId: 18 2559455250: system.mem_ctrls: Write 1766829376, command: ReadReq, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 10632640, command: ReadReq, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 1766829440, command: ReadResp, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 10632704, command: ReadReq, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 10632768, command: WritebackDirty, ContextId: -1, MasterId: 0 2559455250: system.mem_ctrls: Write 10632832, command: WritebackDirty, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 10632896, command: ReadReq, ContextId: -1, MasterId: 0 2559455250: system.mem_ctrls: Write 10632960, command: WritebackDirty, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 10633024, command: WriteReq, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 1766910464, command: WritebackDirty, ContextId: -1, MasterId: 0 2559455250: system.mem_ctrls: Write 1767165376, command: WritebackDirty, ContextId: -1, MasterId: 0 2559455250: system.mem_ctrls: Write 1766735744, command: ReadReq, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 1767165440, command: WriteReq, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 10633152, command: ReadExReq, ContextId: 1, MasterId: 18 2559455250: system.mem_ctrls: Write 1766829504, command: ReadReq, ContextId: 0, MasterId: 14 2559455250: system.mem_ctrls: Write 1766735872, command: ReadExReq, ContextId: 1, MasterId: 18 2559455250: system.mem_ctrls: Write 1766829568, command: WritebackDirty, ContextId: -1, MasterId: 0 2559455250: system.mem_ctrls: Write 10633280, command: WritebackDirty, ContextId: -1, MasterId: 0 I have modified printQs() function to print contextId and masterId as well. Thanks, Prakhar Jawre IIT Kanpur 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