Ship It!

src/mem/ruby/slicc_interface/AbstractController.hh (Diff revision 1)

This doesn't seem like a good idea. This means that every generated controller will now have a pointer to the RubySystem, which may encourage later misuse of the system within the controllers.
I think we should be moving in the other direction instead. Specifically, Ruby's warmup and cooldown processes are simulated-system-wide activities, NOT RubySystem instance-specific. In a single simulation, I could imagine there being multiple simulated systems with separate RubySystem instances, but warmup and cooldown activities may necessarily touch components of both RubySystems (e.g. a shared backing memory being flushed to). Thus, you can't have one instance warming up/cooling down, but the other instance isn't. It doesn't make sense to have separate variables for each instance.
I'd strongly prefer that m_warmup_enabled and m_cooldown_enabled be made into static (class) variables of the RubySystem (this has bugged me for a long time). This would eliminate the need for RubySystem pointers in the abstract system, because these variables could be accessed statically just like the block size. It would also improve the encapsulation of the RubySystem object, which currently has these variables publicly-visible (yuck).
This patch enables functionality that has never existed before, so I'd prefer that we fix the RubySystem variable visibility before pushing this patch.

Show all issues

1. Lena Olson March 21, 2015, 12:33 p.m. (March 21, 2015, 12:33 p.m.)

   I can totally understand why you want to fix the encapsulation, and if someone else wants to make that fix, I'm happy to make the minor changes to update this patch to work with it.  I really just wanted to get this out there for anyone else who wants to restore ruby checkpoints using the default memory type, since I imagine I might not be the only one.

2. Joel Hestness March 23, 2015, 6:56 a.m. (March 23, 2015, 6:56 a.m.)

   After some more digging, all generated controllers have access to the RubySystem with the globally-visible g_system_ptr. If you're not willing to investigate moving the warmup/cooldown variables around, you need to at least use g_system_ptr instead of adding this pointer.

src/mem/ruby/slicc_interface/AbstractController.cc (Diff revision 1)

White space around parens should be consistent with rest of file.

Show all issues

I like the idea of getting it sorted (hopefully we can retire the RubyMemoryControl). I am not sure about the solution though. Surely all the stats for the DRAMCtrl object(s) would be all confused if time advances, but no accesses are counted? Do we not also need to reset all stats once the warmup is sorted?