Just a quick comment from the "Peanut Gallery". :) 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??? Brad From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Korey Sewell Sent: Sunday, April 25, 2010 7:34 PM To: M5 Developer List Subject: Re: [m5-dev] curTick + 1 bugs in Memory System? I'm also open to thoughts about how to handle this better in general... I agree that scheduling things on "curTick+1" just seems wrong, and it is confusing and a potential (and quite possibly current) source of timing model errors, so if there's a clean and easy way to improve it without scheduling lots of extra events then we should consider that. Requiring every SimObject to have a clock and every port to know the clock of its owner is one possibility; it's rather invasive, but maybe it's a good idea anyway. Thoughts from the peanut gallery? Well, every Port already has a "MemObject *owner", so do people think it would it be that much of a stretch to give each MemObject (instead of SimObject) a clock member function? For something like a cache, it would be just the hitlatency but for a Bus or other objects with explicit M5 frequencies, you could just return the appropriate value. Scheduling on the next available tick could potentially just be "curTick + owner->clock" instead of the curTick + 1. -- - Korey
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
