On Mon, Jan 4, 2010 at 12:25 PM, nathan binkert <[email protected]> wrote: >> To answer your question about the ruby tester. While both the ruby tester >> and memtester use false sharing to test coherence, they behave in different >> ways. To my understanding, the Memtester has all cpus write a cache block >> before checking it. Meanwhile the Ruby tester issues only four writes to a >> cache block, before checking it with a read. I believe both testers have >> value. The Memtester uses relatively large global checks, while the ruby >> tester uses smaller more random checks. >> >> I was initially testing the coherence protocols only using the memtester, >> but I noticed that a few later obvious bugs where not being encountered. >> That is why I added the ruby tester. I don't think the ruby tester >> functionality can easily be merge with the memtester. It might be easier to >> merge the memtester with the ruby tester by configuring the number of checks. > > > I don't really care how it gets done, but it seems to me that a long > term goal of merging the two should be there, or at least extracting > duplicate code.
Brad and I discussed this a bit this morning, and my initial assessment is that while both testers are similar in philosophy, the Ruby random tester is a little more sophisticated and directed in implementation, and in the long run should probably supplant the m5 random tester. Brad's experience corroborates this, since the reason he ported it is that it was quicker in detecting errors. There are some other Ruby testers in src/mem/ruby/tester that we should also port over at some point. I'm beginning to think that putting the memory testers under src/cpu isn't such a great idea... while there is some abstract logical consistency (the original reasoning was that the mem tester looks to the memory system like a cpu), it might be more natural to put them under src/mem/tester. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
