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

Reply via email to