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
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
