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
