---------- Forwarded message ---------- From: Derek Hower <[email protected]> To: M5 Developer List <[email protected]> Date: Thu, 30 Jul 2009 23:24:08 -0500 Subject: Re: [m5-dev] GEM5 Issues On Thu, Jul 30, 2009 at 7:46 PM, Beckmann, Brad<[email protected]> wrote: > Hi All, > > Tushar and I have noticed a few issues with GEM5 and we were wondering > if anyone had plans to fix them. If not, we'll go ahead and check in > fixes to the global repository. I just want to make sure we're not > stepping on anyone's toes.
Glad to get some help!! > > - Fix SLICC so that protocol generated files are created in separate > protocol specific folders. Currently they are created in the same > mem/protocol folder overwriting older files (eg. > build/ALPHA_SE/mem/protocol//ControllerFactory.cc). Go ahead with this one. > - Fully integrate SLICC parsing errors into scons. Right now the error > messages don't give any useful info. Should we hold off on fixing this > until SLICCer is added to GEM5? I wouldn't hold off. SLICCer is still indefinitely postponed, at least on my end. I don't expect to work on it until November-ish. Even after SLICCer is around, I think it would be wise to maintain SLICC support for a while so this would be a good fix. > - Support broadcast protocols with NetDest ruby functions. I notices > that one of Derek's recent checkins removed all the NetDest functions in > RubySlicc_ComponentMapping.hh. Most of them were lot old, protocol > specific, and needed to go. However there were a few general ones that > are needed by any broadcast based protocol. Are there plans to add > these back into the tree? Those weren't just removed because they are old. A lot of them were removed because they call a function similar to "mapL2toDirectoryNode," which assumes that there *is* an L2 in the system. We can put these functions back in (and I was planning on doing it as protocols are revisited), but we need to do it in a more generic way. For example, one of the things we are doing to get MESI_CMP_directory working again is removing map_L1CacheMachId_to_L2cache and replacing it with mapToAddressRange(low_bit, high_bit). Low bit and high bit are set at configuration time, and correspond to the address bits that select the L2 bank. If you could be more specific about which functions you're concerned about, we could brainstorm and come up with a new way to do the mapping. > - I appreciate that a lot of the controller assumptions on the ruby side > have been removed. However, it appears that Ruby now assumes a DMA > controller is present. Is there plans to clean this up. I don't think Ruby actually assumes that one is present (if it does it shouldn't). The existing configuration files certainly do, though, mostly because Rocks can't run without one. If you create a configuration that doesn't instantiate a DMA controller, I think you'll be OK. The reason Rocks needs a DMA controller is mostly due to the fact that Ruby handles data now and can't just ignore DMA accesses like it used to. I don't know enough about what M5 does with DMA to know if that is a problem or not. > > Again, we're happy to fix this stuff up ourselves. I just want to be > sure there aren't plans already in progress. > > Thanks, > > Brad > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
