Hi Andreas, Thanks so much for your reply!
I’m not sure whether there is a bug in sendDeferredPacket, but I don’t quite understand why pkt->cmd is altered. Before calling sendTimingReq, pkt->cmd is Writeback, but after calling sendTimingReq and returning true, pkt->cmd becomes ReadReq. I think most of time this change doesn’t matter because this packet is only used by markInService function. The only problem it causes is that mshr->isForwardNoResponse() will check pkt->needsResponse() attribute, which is now altered. Can I just add a data member isForwardNoResponse for mshr, which records whether this mshr is forward without response before calling sendTmingReq? Thanks! Best regards Fangfei From: [email protected] [mailto:[email protected]] On Behalf Of Andreas Hansson Sent: 2013年2月18日 3:33 To: gem5 users mailing list Subject: Re: [gem5-users] question on masterPort.sendTimingReq() function Hi Fangfei, As you suggest, sendTimingReq may change the packet. Thus, if you want to know what the packet looked like before passing it on, you must store the fields in local variables before calling sendTimingReq. You see this done in plenty places throughout the code. If the packet is not accepted (sendTimingReq returns false), then it should be unaltered. Getting back to your error, are you suggesting there is a bug in sendDeferredPacket in that it looks at the attributes of the packet when it shouldn't? Thanks, Andreas From: Fangfei Liu <[email protected]<mailto:[email protected]>> Reply-To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Date: Monday, 18 February 2013 00:16 To: gem5 users mailing list <[email protected]<mailto:[email protected]>> Subject: [gem5-users] question on masterPort.sendTimingReq() function Hi, I’m hacking classic cache model to implement my own cache design. I’m using a two level cache hierarchy and simple memory. I met a very strange assertion fail which I could not figure it out. The failed assertion is as follows: void MSHR::clearDownstreamPending(): Assertion `downstreamPending' failed If I trace back the calling stack, it is called by sendDeferredPacket() function in cache_impl.hh. I have figured out some more detailed information. This function basically sends out request from either miss queue or write buffer. In this specific case, it gets a timing packet from L2 cache write buffer, therefore it is a L2 writeback packet, and MSHR->isForwardNoResponse() is true (do not need response). Also, no new bus packet is generated and the original packet is forwarded to next level (in my case, it is a simple memory). It turns out after calling the function masterPort.sendTimingReq(pkt), pkt is modified and MSHR->isForwardNoResponse() (which depends on mshr->getTarget()->pkt) is no longer true (pkt->cmd becomes ReadReq). I was wondering is there any way that the function sendTimingReq(pkt) can modify the attribute of the packet (such as change pkt->cmd)? By the way, Before successfully send the request, sendDeferredPacket retries several times. Thanks in advance! Best regards Fangfei -- 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 [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
