Hi Tony, Are you saying that registers are *not* being freed upon commit? Even with that being the case, if the ROB size is 1, then I don't see how there is a deadlock with since only a small subset of the physical registers are in flight at any given time.
Maybe Xiangyang forgot to set his ROB/InstQueue sizes appropriately? On Mon, Jul 15, 2013 at 11:16 AM, Anthony Gutierrez <[email protected]>wrote: > I think you could get a deadlock if you set the number of physical > registers equal to architectural registers because you won't have enough > free list entries, this is an Alpha style architecture where entries in the > rename table aren't freed until they're overwritten. I think you need to > set physical registers >= max number of arch registers + max number of > instructions in flight (ROB size). > > Perhaps you're running into a similar issue with your rename changes. > > Anthony Gutierrez > http://web.eecs.umich.edu/~atgutier > > > On Mon, Jul 15, 2013 at 1:56 PM, Xiangyang Guo <[email protected]> wrote: > >> Hi, Korey, >> >> Thanks for reply. About your suggestion " 1) Why do anything to rename? >> Instead, why dont you change the number of physical registers to equal the >> number of architectural/logical registers?" , I think we did the same >> thing. If I understand right, the default prev_reg is set to architectural >> regs when the rename_map initialized. And then prev_reg's value changed >> during the simulation. So I just make the renamed_reg=prev_reg. Please >> correct me if I'm wrong. Thanks >> >> Regards >> >> Xiangyang >> >> >> On Mon, Jul 15, 2013 at 12:09 PM, Korey Sewell <[email protected]> wrote: >> >>> Suggestions: >>> 1) Why do anything to rename? Instead, why dont you change the number of >>> physical registers to equal the number of architectural/logical registers? >>> >>> 2) To debug, run the same benchmark with the SimpleCPU and compare the >>> committed instructions to your run. You should be able to figure out where >>> you simulation breaks (i.e. last committed instruction) and also track down >>> which instruction should be providing data to the instruction stuck in the >>> ROB. >>> >>> >>> On Sat, Jul 13, 2013 at 8:13 PM, Xiangyang Guo <[email protected]> wrote: >>> >>>> Hi, Gem5-users, >>>> >>>> I need to use in order CPU for ARM ISA, so I need to modify O3 to >>>> InOrder. >>>> >>>> I disable the rename part by keeping the renamed reg same as prev reg, >>>> also change all the widths to 1 to keep in order issue and exe. In term of >>>> WAW and WAR, I just add a flag to each reg, if one inst is in the pipeline, >>>> I mark the flag of its regs to 1. And if one inst wants to insert to the >>>> InstQueue, first check the dest reg's flag, if the flag is 1 meaning there >>>> is WAW/WAR, should block(tid), I bind this checking with isfull() together >>>> because I think they are doing the similar thing, which decides whether >>>> inserting this inst or not. >>>> >>>> But then I get the error : >>>> Exiting @ tick 9223372036854775807 because simulate() limit reached >>>> >>>> It seems that I get a deadlock, And I also get the trace and find that >>>> the one inst stays in the ROB and cannot be ready for a long time. >>>> >>>> So could you give me some suggestion about this? Any hint is >>>> appreciable. >>>> >>>> Thanks >>>> >>>> Xiangyang >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> >>> >>> >>> -- >>> - Korey >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
