Hi sir；
I am learning about the gem5 coherentXbar, and in the Xbar.hh two
variables make me confused which are waitingForPeer and waitingForLayer
From the code flow,
I think the waitingForPeer is used to point to a master/memSide port who’s peer
is busy and can not accept the request
And it is assigned in the Layer:;failTiming function which is called in
the CoherentXBar::recvTimingReq after a memSidePort->tryTiming fail or
memSidePort->sendTimingReq fail ,
and the fail is because if the peer is not ready to accept the request , am I
right here?
And in the waitingForLayer are ports being pushed in BaseXBar::Layer<SrcType,
DstType>::tryTiming function when the ReqLayer is busy, which means that the
cpuSideport of xbar is not ready to accept the request
And the cupSidePort which is busy itself will be pushed into the
waitingForLayer.
But the waitingForPeer is moved into waitingForLayer in
BaseXBar::Layer<SrcType, DstType>::recvRetry() function, which is called in
CoherentXBar::recvReqRetry(PortID mem_side_port_id) function,
and the recvReqRetry is always called because the peer is ready and call the
sendReqRetry().
>From my point of view, when the peer is ready to accept a request, and when
>recvReqRetry of the master port iscalled, the master port should call the
>sendTimingReq to resend the request.
But because the waitingForPeer is moved into waitingForLayer, the master port
which was pointed by waitingForPeer will try to send request by Layer::
sendRetry which is called in BaseXBar::Layer<SrcType, DstType>::retryWaiting()
And the Layer:: sendRetry will actually implemented in the subclass which is
ReqLayer/ RespLayer/ SnoopRespLayer, and the sendRetryResp/ sendRetryReq/
sendRetrySnoopResp is called NOT the sendTimingReq
And this does NoT match the mem protocol when slave is busy (see gem5: Creating
SimObjects in the memory
system<https://www.gem5.org/documentation/learning_gem5/part2/memoryobject/>,
if the picture below is not showed correctly)
And I think the reason of this is because the Xbar doesn’t distinguish the two
retry senarios when xbar::cpuSidePort is busy and when the peer of
xbar::memSidePort is busy
In both scenario, xbar put the port into waitingForLayer as said above, but the
the flow of this scenario is different.
[cid:image003.jpg@01D91C6C.D4DC66C0]
Felix guo
Shannxi Xi’an
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
