Hi, I make the InstQueue size to 1 to make sure inorder issue, but I did not make any change to ROB because I think ROB doesn't harm anything. Did I miss something here ? Thanks
On Mon, Jul 15, 2013 at 2:40 PM, Korey Sewell <[email protected]> wrote: > 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
