gem5-users@gem5.org

The gem5 Users mailing list

View all threads

waitingForLayer xbar assertion fail

AA
Abdlerhman Abotaleb
Mon, Sep 12, 2022 12:55 AM

P {margin-top:0;margin-bottom:0;} I'm trying to send many memory requests with short time separation

The following error happened

"""""""""""""

gem5.debug: build/RISCV/mem/xbar.cc:199: bool gem5::BaseXBar::Layer<gem5::ResponsePort,

gem5::RequestPort>::tryTiming(SrcType *)

[SrcType = gem5::ResponsePort, DstType = gem5::RequestPort]:

Assertion `std::find(waitingForLayer.begin(), waitingForLayer.end(), src_port) == waitingForLayer.end()' failed.

"""""""""""""""""""""""""""""""""""

It happens inside the following function:

"""

template <typename SrcType, typename DstType> bool

BaseXBar::Layer<SrcType, DstType>::tryTiming(SrcType* src_port)

{

// if we are in the retry state, we will not see anything but the

// retrying port (or in the case of the snoop ports the snoop

// response port that mirrors the actual CPU-side port) as we leave

// this state again in zero time if the peer does not immediately

// call the layer when receiving the retry

// first we see if the layer is busy, next we check if the

// destination port is already engaged in a transaction waiting

// for a retry from the peer

if (state == BUSY || waitingForPeer != NULL) {

// the port should not be waiting already

//Abotaleb : @todo :: FInd why this assertion happens in case of fast inter-arrival between requests

assert(std::find(waitingForLayer.begin(), waitingForLayer.end(),

src_port) == waitingForLayer.end());

// put the port at the end of the retry list waiting for the

// layer to be freed up (and in the case of a busy peer, for

// that transaction to go through, and then the layer to free

// up)

waitingForLayer.push_back(src_port);

return false;

}

state = BUSY;

return true;

}

"""""

Is there any idea why such asserion happen and how to eliminate it ?

Thank you in advance.