Thanks for your advice. My guess is that it's the ports connected to the atomic-only port converts a timing request to atomic, and calls the recvAtomic function. In this case it's the XBar. I will try to measure how it's delayed.
________________________________ From: Jason Lowe-Power <[email protected]> Sent: Wednesday, July 6, 2022, 11:09 a.m. To: The gem5 Users mailing list <[email protected]> Subject: [gem5-users] Re: What happens when a atomic only port is accessed in Timing simulation? Hi Zehan, Atomic memory accesses should not be used during the same simulation loop as timing accesses. I.e., you should not call "sendAtomic" on a port during the same simulation loop that you call "sendTiming". If there isn't a panic in that case, there probably should be. If you want to get a value out of memory in 0 time (e.g., for debugging or to model a "perfect" hardware component) you can use *functional* accesses during the timing simulation. You can also exit the simulation loop and switch between timing and atomic modes. Cheers, Jason On Tue, Jul 5, 2022 at 9:56 PM Zehan Gao <[email protected]<mailto:[email protected]>> wrote: Hi All, I am building a simulated system with a control registers port that only implemented recvAtomic function. The control port is connected to the IOBridge, and the system is running in timing mode. There is no problem to access the registers from CPU, but I wonder what the system does with the delay? I believe the atomic port would be treated as a timing port that has no delays. But is the delay of IOBridge and other system buses counted? Thanks, Zehan _______________________________________________ gem5-users mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ gem5-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
