Hi everyone,
I have a doubt regarding the operation of the recvAtomic() function in the
memory controller. I can see that recvAtomic() calls recvAtomicLogic(),
which returns the access latency from the memory interface. If I change the
code to:
return mem_intr->accessLatency() + 100;
Does this mean that it will take 100 more ticks for the memory controller
to access the memory? If yes, then how can I visualize this change? The
AMAT stats in stats.txt are giving me 'nan' and even with the debug flags
on, I cant exactly measure this change. Any help would be appreciated!
--
Regards,
John Smith
Hi John,
What's the exact stat you are looking at for AMAT? My guess is that it is
not getting updated for Atomic mode memory accesses.
interface. If I change the code to:
return mem_intr->accessLatency() + 100;
Does this mean that it will take 100 more ticks for the memory controller
to access the memory? If yes, then how can I visualize this change?
Yes, this means that the response from the controller will be delayed by
100 ticks. In case you are looking for a more detailed timing model, and
need to use Timing memory accesses, you can do something similar (adding
delay) by tweaking memory controllers' frontEnd and backEnd latency
parameters.
-Ayaz
On Thu, Jul 6, 2023 at 4:46 PM John Smith via gem5-users <
gem5-users@gem5.org> wrote:
Hi everyone,
I have a doubt regarding the operation of the recvAtomic() function in the
memory controller. I can see that recvAtomic() calls recvAtomicLogic(),
which returns the access latency from the memory interface. If I change the
code to:
return mem_intr->accessLatency() + 100;
Does this mean that it will take 100 more ticks for the memory controller
to access the memory? If yes, then how can I visualize this change? The
AMAT stats in stats.txt are giving me 'nan' and even with the debug flags
on, I cant exactly measure this change. Any help would be appreciated!
--
Regards,
John Smith
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-leave@gem5.org