Hey guys, Per Malek's suggestion, I updated our protocol config scripts to make system.ruby the Python parent of the caches, directory and DMA controllers, and this appears to have side-stepped the bug by making all of the MessageBuffers and other Ruby components use the Ruby system for m_clockobj_ptr (i.e. they're all in the same clock domain). This now passes our regressions with default settings.
I still need to verify that our scripts that allow setting frequency of certain components will play nice with this change, but in general, I'm in agreement with Andreas that the timing of Messages through the MessageBuffers should be flexible enough to allow clock domains boundary traversal within Ruby (e.g. in most current CPUs, L1 caches are clocked at the core frequency, while lower levels of cache, directories and memory controllers are clocked at "uncore" frequencies). I may be able to look at this more deeply soon. Joel On Mon, Jan 21, 2013 at 5:34 PM, Nilay <[email protected]> wrote: > On Mon, January 21, 2013 5:09 pm, Andreas Hansson wrote: > > Hi everyone, > > > > It's a bit outside my domain, but is the MessageBuffer not where you > would > > typically bridge two clock domains in Ruby? If this is where it would > > happen, then perhaps the best solution is to "fix" the test to be more > > forgiving (or even remove it). > > > > You are right that the message buffer is a bridge between clock domains. > Your solution might work since all the messages entering the buffer come > from the same domain. > > Joel, are you explicitly setting the frequency of the network? If I recall > correctly, in the default case network runs at Ruby's frequency. In fact, > Garnet and Simple Network heavily rely on g_system_ptr->getTime() > function. > > -- > Nilay > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://www.cs.utexas.edu/~hestness _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
