After digging deeper, I set the system.ruby._cpu_ruby_ports[i].access_phys_mem = False in ruby_fs.py and this caused my simulation to hang. I am running in Alpha with fullsystem mode.
On Mon, Feb 24, 2014 at 10:44 PM, GE ZHIGUO <[email protected]> wrote: > Hi, Zhao Hui > > To my knowledge, Ruby supplies data to CPU and I remember that ruby writes > data to cache. > > Thus, If I am not wrong, the program execution output SHOULD probably > produces wrong outputs if there is problem with cache protocol modeled by > ruby. > > Regards, > > Zhiguo > > > > > > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *Hui Zhao > *Sent:* Tuesday, February 25, 2014 11:32 AM > *To:* gem5 users mailing list > *Subject:* [gem5-users] changing data content ruby caches does not affect > program result > > > > I am using ruby and its cache protocol in my simulation. I found that even > I intentionally return wrong data in a cache access, I always get the same > result. > > Then I modified the hitCallback() in Sequencer.cc. I reset all data to > zero before it get written/read. I still get the same result. > > I found this old post > > http://www.mail-archive.com/gem5-users%40gem5.org/msg01519.html > > It seems to me that ruby is still just doing timing related simulation, > and data returned by ruby cache access does not change the program output. > If this is true, does this mean that we can't use ruby to verify the > correctness of a cache protocol? > > Thanks > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
