Hi guys, Currently, there are a handful of bugs that are interfering with the drain, checkpoint and restore functionality when running sims with Ruby. I've documented observable bugs in this GoogleDoc<https://docs.google.com/spreadsheet/ccc?key=0AvwlHlT78qDYdFU1clZlemYyelQxTEZyeXNBck9hNkE#gid=1>, and I'm currently working my way through trying to fix things.
The biggest challenge I've run into is in the RubyPort drain function, which uses the drain functionality of the new QueuedMasterPort and QueuedSlavePort (changeset 8914:8c3bd7bea667) during simulation after a system-wide drain call (i.e. when called from drain() in simulate.py). To sort through this, I need to confirm the desired semantics of the drain function to determine whether fixes should be made in RubyPort or the PacketQueue. From what I observe in a handful of different SimObjects, the drain function should: 1) only be called during a system-wide drain process 2) return 0 if the component is drained, and return 1 if the component has work to do before it can be considered "drained" Further, in the case where some components need to be drained, the drain() function in simulate.py will call simulate(), which will run simulation until each of the components that returned 1 from their drain functions have cleared the work that needed to be drained (they signal their completion by calling process on the drain event). If the above are the desired semantics, then I believe that the RubyPort should NOT be calling drain() on its ports while in the simulate() phase of execution (which it currently does). If the RubyPort does call drain during the simulate phase, then its ports that have received new work since the system-wide drain call will no longer be considered "drained", though they weren't counted toward the currently executing CountedDrainEvent. This can result in the CountedDrainEvent being processed too many times. Please let me know if this sounds correct. Thanks, Joel -- 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
