Well, you have likely set up a nasty time bomb here. What you are basically doing is assuming that - Valid data contained in the network is always present in a controller as well - Or the backing store data (memory) is up to date. Only in that case you can forget about the data in the network as long as you look for data in all controllers. I believe this property is not true for most protocols, including CHI and the one I am working on for a living.
However, it won't crash until the only place where valid data is present is the network AND the corrupted data you get back is critical enough to cause a visible bug. You could then get away with this for weeks, months or even years... Until the bug kicks in. And good luck finding that it comes from a bad functional read at that point. I would personally: 1. duplicate all functionalWrite methods in the garnet directory 2. rename these duplicates functionalRead (and return bool instead of uint32_t) 3. replace calls to functionalWrite in their bodies with calls to functionalRead on the same component. It shouldn't take more than an hour to duplicate the 35 occurrences of functionalWrite in the garnet directory ;). You can then verify this is correct with ruby_mem_test.py using --num-cpu=8 and --functional=50 or so. I recommend running that over night to see if it detects any data corruption. If it passes, you should be good to go. If it doesn't... Welcome to ruby debugging hell. Cheers, Gabriel _______________________________________________ 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
