> Several weeks ago I noticed the same issue with the Ruby Port’s timing port > and made a similar change to Ruby as the change described below. Though it > is a little invasive to include the clock with every MemObject, it is rather > confusing to look at a debug trace and see events going off at tick …001. > > > > If I remember correctly, Nate mentioned some feature or idea he had that > also assigned objects a particular clock value???
Basically, the idea was to create a ClockedObject that derived from SimObject and had the notion of a clock period and phase and a couple helper functions for scheduling events on clock edges. (The default period and phase would be Parent.clock and Parent.clock_phase) I more or less have all of the pieces together. We could easily just change a bunch of classes that derive from SimObject to instead derive from ClockedObject. Another nice feature is that I've added support for specifying latencies in terms of cycles for clocked objects. So just as you can say '3ns' or '1t', you can now say '3c' which means 3 cycle latency. 3c essentially gets translated to "3 * Self.clock.latency" I can try to get those changes to the head of my patch queue and send them out for review. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
