P {margin-top:0;margin-bottom:0;} Hello All, I'm trying to implement a simulation memory object that accepts atomic requests on its CPUSide port (response port) and forwards them to the memory controller.

This simulation object is connected to cache from the CPUSidePort and to Memory controller from memSidePort.

It works fine with timing requests and responses.

For Atomic requests, I override the recvAtomic making it calls sendAtomic in the Request port

Inside the CPUSidePort(which is defined inside the simulation object scope , inherit from ResponsePort) :

Tick recvAtomic(PacketPtr pkt) override
{
owner->handleAtomic(pkt); // handleAtomic defined in the simulation object
}

& Inside the Simulation object:

void
simulationMemObect::handleAtomic(PacketPtr pkt)
{

memSidePort.sendAtomic(pkt);
}

I don't know how to implement the response receive handling , there's no function to override called recAtomicResp , similar to recvTimingResp in TimingRequestProtocol (One of RequestPort class parents).

For now, If run GEM5 , it ends with core dump at the beginning with the following output when try to debug with GDB:

received signal SIGILL, Illegal instruction.

0x000000000117bdf1 in

gem5:: simulationMemObect ::CPUSidePort::recvAtomic(gem5::Packet*)

Hi,

You can get a refresher about the various transaction types here: https://www.gem5.org/documentation/general_docs/memory_system/

Here is an excerpt about atomic transactions from that page: “When a atomic access is sent the response is provided when the function returns.” Specifically, the packet argument that is passed from an atomic handler to the next must be used to store all the information needed by the SimObjects on access path. The request path (forward) is composed of the successive calls to handleAtomic and the response path (backward) is composed of the successive returns from these handlers. The “atomic” aspect comes from the fact that the requestor can’t perform any action during the atomic access as opposed to a regular timing access that has the request path separated from the response path.

In your case, the handleAtomic function is almost correct. But you will notice that recvAtomic should return a Tick value that represents the latency introduced by the current SimObject. The crash you are facing must come from not returning a value before the end of a function that does not return void. Compilers can insert a special instruction (like ud2 in X86) that will cause an immediate illegal instruction error when reaching various undefined behaviour situations to catch the programmer attention.

Just return your module latency in Tick (preferably using ClockedObject::cyclesToTicks) from handleAtomic() and return that value from recvAtomic().

Best,

Gabriel