Hi,
Just a quick check to see if I got this right. I know that if a missed
request does not need a response, then the downstream packet that is
sent out to service it will be the original request as it came in; or at
least, for missed requests that came in from the CPU-side. In
getTimingPacket(), this corresponds to the mshr->isForwardNoResponse()
check.
Otherwise, getBusPacket is called to create a downstream packet of the
appropriate command type based on the original packet. This method may
still return NULL if the original packet does not require a response. In
this case, getTimingPacket notices this yet still sends out a newly
created packet and marks mshr->isForward which is then checked by
handleFill. Evidently this would be the case for no-response packets
that didn't originate from the CPU.
I just wanted to confirm that the reason why mshr->isForward isn't set
for no-response packets originating from the CPU is because
isForwardNoResponse()-MSHRs get recycled immediately after their
downstream request is sent (by virtue of MSHR::markInService) which
would effectively kill the isForward flag. Other sources maintain their
MSHR, allowing us to check for the flag afterwards.
It was just a little confusing to see one case where the MSHR->isForward
flag gets set before sending out a no-response packet, while the other
case it doesn't get set (even though it's clearly also a no-response
packet).
I was also hoping someone could describe a small scenario in which the
isForward flag is used, because I'm having a little trouble seeing where
these snoop-side no-response MSHR requests fit in. As far as I can tell
it's only used in handleFill to see if it has stuff to fill (i.e. if it
should expect to find a response in the packet).
Cheers,
-- Jeroen
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
