Okay, I got it. I'll simulate and try it out. I also wanted to ask how I should go about configuring a 3-level cache hierarchy in fs.py. Could you please let me know if the following configurations are correct? Do I need to add any other arguments (that are cache related. I've already added arguments referring to disk image and the kernel)? /build/X86/gem5.opt ./configs/example/fs.py --cpu-clock=1GHz \ -n 8 \ --mem-size=16GB \ --num-l2caches=8 --num-l3caches=1 \ --l1d_size=20KB --l1i_size=20KB --l2_size=512KB --l3_size=4MB \ --l1d_assoc=8 --l1i_assoc=8 --l2_assoc=8 --l3_assoc=64 \ --cacheline_size=64 \ On Fri, Jul 7, 2023 at 1:49 PM Ayaz Akram <yazakram@ucdavis.edu> wrote: > Hi John, > > The recvAtomic() change should work if your memory mode is "Atomic". It > will not work if you are using "Timing" memory mode. I don't know what > configuration you are simulating. If the memory mode is "Atomic" with > Atomic CPU type, I think you should be able to see the impact of your > change on the cpu.numCycles (total cycles taken to run the simulation). The > real impact would depend on the characteristics of the benchmark. > > -Ayaz > > On Fri, Jul 7, 2023 at 10:09 AM John Smith <johnsmith20013500@gmail.com> > wrote: > >> Thanks for the response, Ayaz. I just want to visually see the change in >> the latencies of memory accesses if I increase the latency by 100 ticks (or >> more). Is tweaking the frontEnd and backEnd latency the only way for that? >> It won't work with the change in recvAtomic() ? >> >> On Thu, Jul 6, 2023 at 10:46 PM Ayaz Akram <yazakram@ucdavis.edu> wrote: >> >>> 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 >>>> >>>