A good question to ask is what is the last committed instruction? Can you match that inorder trace with a trace from the simple-timing model? When you do that, you can find what instruction needs to be committed next and see if there was some type of scheduling problem with it.
On Sun, Nov 28, 2010 at 12:41 AM, Gabe Black <[email protected]> wrote: > You should check to see if InOrder is getting stuck or loosing track of what > it's doing/needs to do and not scheduling any new cpu cycles after a while. > For that many ticks to have passed I expect the event queue must have > emptied and the sentry event at the end triggered. > > Gabe > > On 11/27/2010 9:36 PM, Veydan Wu wrote: > > Hi, when I run spec2006 using InOrderCPU, several programs exited because of > reaching maximum tick: > > Exiting @ cycle 9223372036854775807 because simulate() limit reached > > I think this is quite impossible because I run the programs for several > hours and I have run them using atomic cpu and it is safe after several > dozens of billions of instructions. Can anyone tell me why the cycle number > in InOrderCPU would increase so fast? Thanks. > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > -- - Korey _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
