Hi
>It tried to terminate after the first cycle, but it looks like it kept executing for several cycles afterwards. It kept printing out the following messages: What is the end cycle? 1000? >In one case, it executed 15k cycles very quickly, and then took a couple of hours executing another 5k cycles and it still hadn't stopped the simulation Are you sure this behavior is the result of saving stats every cycle? Are you using trace? Timing? -- Regards, Mahmood ------------------------- FROM: Jason Zebchuk <[email protected]> TO: "[email protected]" <[email protected]> SENT: Friday, March 29, 2013 5:11 AM SUBJECT: Inorder simulation not stopping gracefully Hi guys, We tried running a simulation using the inorder core instead of the out-of-order core, and we ran into a little problem. We did: flexus.set "-magic-break:stop_cycle" "1" to stop after a single cycle. It tried to terminate after the first cycle, but it looks like it kept executing for several cycles afterwards. It kept printing out the following messages: <breakpoint_tracker.cpp:447> {1}- Reached target cycle. Ending simulation. <flexus.cpp:717> {1}- Terminating simulation. Timestamp: 2013-Mar-28 20:02:51 <flexus.cpp:718> {1}- Saving final stats_db. This was repeated over and over (with the cycle number incrementing by one each time) until the simulation eventually stopped. It looks like it's waiting for outstanding memory requests to terminate before exiting the simulation. Is this the normal behavior with the in-order core? The real problem is that each cycle it tries to save the statistics. When we try running longer simulations, the statistics get rather large so it advances very slowly. We also saw cases where it would continue running for several hours after it should have terminated. In one case, it executed 15k cycles very quickly, and then took a couple of hours executing another 5k cycles and it still hadn't stopped the simulation. I'm not sure if this is an issue with the memory hierarchy taking a long time to complete all of the outstanding requests, or if there's some other bug in this case. Any thoughts you might have would be useful. Thanks, Jason
