Hi gem5 users, Going further down exploring network on chip use cases. I tried to come back to a simple example using garnet synthetic traffic to see where it was possible to existing NoC models with known DDR models. I take for example the DDR5_8400_4x8 model which has a theoretical peak of 33613 MiBytes/s as I can see from the ouput stats.txt file for example. However, when I run simulations I can never reach that bandwidth and it seems to be due to the fact, that at some point, the memory controller just stops responding to requests. Taking gem5 from the stable branch. I run the following : scons build/NULL/gem5.debug -j `nproc` PROTOCOL=Garnet_standalone ./build/NUL/gem5.dbeug ./configs/example/garnet_synth_traffic.py --link-width-bits=64 --num-cpus=4 --num-dirs=1 --network=garnet --topology=CrossbarGarnet --num-packets-max 1_000_000 --sim-cycles=4200 --synthetic=neighbor --injectionrate=1 --mem-type DDR5_8400_4x8 ./build/NUL/gem5.dbeug ./configs/example/garnet_synth_traffic.py --link-width-bits=64 --num-cpus=4 --num-dirs=1 --network=garnet --topology=CrossbarGarnet --num-packets-max 1_000_000 --sim-cycles=1_000_000 --synthetic=neighbor --injectionrate=1 --mem-type DDR5_8400_4x8 Both simulations provided plateau at 64 Bytes read from memory for each controller. This is extremely weird behavior that I can't explain to myself. I attached the stats.txt file I get as output. Since the controller stops sending, simulating more cycles only leads to decreased bandwidth of course. Is this a bug, or am I misusing the framework somehow ? Thanks in advance, Regards, Xomse

Hi Xomse, I don't exactly know what's causing this, but I would encourage you to carefully trace the python script you're executing. You cannot assume that command line options do what they seem to do. My first guess is that this is a problem with the script and gem5's configuration. Cheers, Jason On Thu, Jun 12, 2025 at 2:07 AM xomse via gem5-users <gem5-users@gem5.org> wrote: > Hi gem5 users, > > Going further down exploring network on chip use cases. I tried to come > back to a simple example using garnet synthetic traffic to see where it was > possible to existing NoC models with known DDR models. > > I take for example the DDR5_8400_4x8 model which has a theoretical peak > of 33613 MiBytes/s as I can see from the ouput stats.txt file for example. > > However, when I run simulations I can never reach that bandwidth and it > seems to be due to the fact, that at some point, the memory controller just > stops responding to requests. > > Taking gem5 from the stable branch. I run the following : > > scons build/NULL/gem5.debug -j `nproc` PROTOCOL=Garnet_standalone > ./build/NUL/gem5.dbeug ./configs/example/garnet_synth_traffic.py > --link-width-bits=64 --num-cpus=4 --num-dirs=1 --network=garnet > --topology=CrossbarGarnet --num-packets-max 1_000_000 --sim-cycles=4200 > --synthetic=neighbor --injectionrate=1 --mem-type DDR5_8400_4x8 > > ./build/NUL/gem5.dbeug ./configs/example/garnet_synth_traffic.py > --link-width-bits=64 --num-cpus=4 --num-dirs=1 --network=garnet > --topology=CrossbarGarnet --num-packets-max 1_000_000 > --sim-cycles=1_000_000 --synthetic=neighbor --injectionrate=1 --mem-type > DDR5_8400_4x8 > > Both simulations provided plateau at 64 Bytes read from memory for each > controller. > This is extremely weird behavior that I can't explain to myself. > I attached the stats.txt file I get as output. > > Since the controller stops sending, simulating more cycles only leads to > decreased bandwidth of course. > > Is this a bug, or am I misusing the framework somehow ? > > Thanks in advance, > > Regards, > > Xomse > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-leave@gem5.org >