Hi Tushar Thank you very much for the above clarification.
Thank You Chamika On Sat, Jul 25, 2020 at 12:59 AM Krishna, Tushar <tus...@ece.gatech.edu> wrote: > Hi Chamika, > To support multiple clock domains, there’s a difference between simulation > ticks and cycles. Thats probably the source of your confusion. > I’ll let Srikant (cc:d) answer your specific question wrt the specific > events you saw when enabling the debug messages (and managing the > changes/updates to garnet that’ll get pushed to the next version of gem5). > > Best, > Tushar > On Jul 24, 2020, 3:17 PM -0400, Chamika Sudusinghe via gem5-users < > gem5-users@gem5.org>, wrote: > > Hi Jason and All, > > Thank you very much for your suggestion, Jason. I used '1ps' instead of > '1ns' and was able to get rid of the warning there. > > Then when I wanted to debug the network used "--debug-flags=RubyNetwork" > and it > did not print debug messages when sim-cycles=1000. > > http://tusharkrishna.ece.gatech.edu/teaching/garnet_gt/ > > Following is a part of the printed debug message. > > info: Entering event queue @ 0. Starting simulation... > Exiting @ tick 1000 because Network Tester completed simCycles > > It was the same for sim-cycles=10000 as well. Debug messages were printed > for > sim-cycles=100000 but started from the 12500th cycle. > > Following is a part of the printed debug message. > > info: Entering event queue @ 0. Starting simulation... > warn: Replacement policy updates recently became the responsibility of > SLICC state > machines. Make sure to setMRU() near callbacks in .sm files! > 12500: system.ruby.network.netifs10: Network Interface 10 connected to > router 10 woke up > at time: 25 > 13500: system.ruby.network.routers10: Router 10 woke up > 13500: global: SwitchAllocator at Router 10 granted outvc 0 at outport > South to invc 0 > at inport Local to flit [flit:: Id=0 Type=3 Vnet=0 VC=0 Src NI=10 Src > Router=10 Dest NI=18 > Dest Router=2 Enqueue Time=25 ] at time: 27 > 13500: global: Router 10 OutputUnit 2 decrementing credit for outvc 0 at > time: 27 > 13500: global: CrossbarSwitch at Router 10 woke up at time: 27 > 14500: system.ruby.network.netifs10: Network Interface 10 connected to > router 10 woke up > at time: 29 > 14500: system.ruby.network.routers06: Router 6 woke up > 14500: global: SwitchAllocator at Router 6 granted outvc 0 at outport > South to invc 0 at > inport North to flit [flit:: Id=0 Type=3 Vnet=0 VC=0 Src NI=10 Src > Router=10 Dest NI=18 > Dest Router=2 Enqueue Time=25 ] at time: 29 > 14500: global: Router 6 OutputUnit 2 decrementing credit for outvc 0 at > time: > 29........ > > The answer was similar for sim-cycles=1000000 as well. > > The above changes to the sim-cycles were done while keeping tick rate as > "1ps". > > ---------------- > > Then I tried changing the tick rate to '10ps'. > > sim-cycles=1000 -> no debug messages > sim-cycles=10000 -> debug messages started from 1250th cycle > sim-cycles=100000 -> debug messages started from 1250th cycle > > ---------------- > > Then I tried changing the tick rate to '100ps'. > > sim-cycles=1000 -> debug messages started from 125th cycle > sim-cycles=10000 -> debug messages started from 1250th cycle > sim-cycles=100000 -> debug messages started from 1250th cycle > > ---------------- > > Then I tried changing the tick rate to '1ns'. > > sim-cycles=1000 -> debug messages started from 14th cycle > > info: Entering event queue @ 0. Starting simulation... > warn: Replacement policy updates recently became the responsibility of > SLICC state > machines. Make sure to setMRU() near callbacks in .sm files! > 14: system.ruby.network.netifs10: Network Interface 10 connected to > router 10 woke up > at time: 14 > 16: system.ruby.network.routers10: Router 10 woke up > 16: global: SwitchAllocator at Router 10 granted outvc 0 at outport > South to invc 0 > at inport Local to flit [flit:: Id=0 Type=3 Vnet=0 VC=0 Src NI=10 Src > Router=10 Dest NI=18 > Dest Router=2 Enqueue Time=14 ] at time: 16 > 16: global: Router 10 OutputUnit 2 decrementing credit for outvc 0 at > time: 16 > 16: global: CrossbarSwitch at Router 10 woke up at time: 16 > 18: system.ruby.network.netifs10: Network Interface 10 connected to > router 10 woke up > at time: 18 > 18: system.ruby.network.routers06: Router 6 woke up > 18: global: SwitchAllocator at Router 6 granted outvc 0 at outport > South to invc 0 at > inport North to flit [flit:: Id=0 Type=3 Vnet=0 VC=0 Src NI=10 Src > Router=10 Dest NI=18 > Dest Router=2 Enqueue Time=14 ] at time: 18. > > ---------------- > > Increasing above '1ns' results in "fatal: system.ruby.clk_domain has a > clock > period of zero". > > ---------------- > > Summarized > > 1ps - starting from 12500th cycle (had cyles with 1000 windows like 12500, > 13500, ...) > 10ps - starting from 1250th cycle (had cyles with 100 windows like 1250, > 1350, ...) > 100ps - starting from 125th cycle (had cyles with 100 windows like 125, > 135, ...) > 1000ps = 1ns - starting from 14th cycle (had iterative debug messages for > the cycles like > 14,16, 18, ...) > > So it is obvious that when having the tick rate as '1ps' it is not > possible to > debug the first 1000 or 10000 cycles because the first one is the 12500th > cycle. > > But when the tick rate is equal to 1ns though it starts from the 14th > cycle, the results > are iterative till the 1000th cycle. > > ---------------- > > I have two questions arising from these results. > > 1. Is the first debug message the starting point of the simulation? If it > is not, what is > the starting point? > 2. Why there are gaps (1000 or 100 or 10 depending on the tick rate) in > the debug messages > apart from when the tick rate is 1ns, where gaps are reduced to multiples > of 2? > 3. Is there any theoretical explanation of what is happening here? > > Thank You > Chamika > > On Fri, Jul 24, 2020 at 8:40 PM Jason Lowe-Power <ja...@lowepower.com> > wrote: > >> Hi Chamika, >> >> I believe the problem is that the default tick rate for garnet tests is >> too small. See this line: >> https://gem5.googlesource.com/public/gem5/+/refs/heads/master/configs/example/garnet_synth_traffic.py#148. >> >> >> You can change that line to '1ps' (or get rid of it altogether which >> would set the tick rate to the default of 1ps) to overcome this issue. >> >> Cheers, >> Jason >> >> On Thu, Jul 23, 2020 at 2:28 AM chamika.sudusinghe--- via gem5-users < >> gem5-users@gem5.org> wrote: >> >>> Hi All, >>> >>> I have installed gem5 recently and currently following the tutorials and >>> the documentation. When I was running, I continuously receive the following >>> warning. >>> >>> Global frequency set at 1000000000 ticks per second >>> warn: rounding error > tolerance >>> 1.250000 rounded to 1 >>> warn: rounding error > tolerance >>> 1.250000 rounded to 1 >>> warn: rounding error > tolerance >>> 1.250000 rounded to 1 >>> warn: rounding error > tolerance >>> 1.250000 rounded to 1 >>> warn: rounding error > tolerance >>> 1.250000 rounded to 1 >>> >>> I have used the example commands given in the documentation ( >>> https://www.gem5.org/documentation/general_docs/ruby/garnet_synthetic_traffic/) >>> as follows and the above warning was received. >>> >>> commands: >>> >>> scons build/NULL/gem5.debug PROTOCOL=Garnet_standalone >>> >>> ./build/NULL/gem5.debug configs/example/garnet_synth_traffic.py \ >>> --num-cpus=16 \ >>> --num-dirs=16 \ >>> --network=garnet2.0 \ >>> --topology=Mesh_XY \ >>> --mesh-rows=4 \ >>> --sim-cycles=1000 \ >>> --synthetic=uniform_random \ >>> --injectionrate=0.01 >>> >>> Please assist me in resolving this issue. >>> >>> Thank You >>> Chamika >>> _______________________________________________ >>> gem5-users mailing list -- gem5-users@gem5.org >>> To unsubscribe send an email to gem5-users-le...@gem5.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>
_______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
