By the way, in the inst_queue file, there's another scoreboard ( RegScoreboard ) to be used in the addtodependent part, so why wont we use the scoreboard like we use in rename/iew stage? Does this scoreboard( RegScoreboard) have special meaning? Or just for simplify ?
Thanks Xiangyang On Wed, Jul 17, 2013 at 5:58 PM, Xiangyang Guo <[email protected]> wrote: > Hi, > > I modify the scoreboard.cc to make another scoreboard ( it is simply > another vector like the original one but contains different info) to > maintain the information if one reg is used now. It works like this: at the > dispatch stage, after one inst is dispatched successfully, then mark all > its regs is used. And at the commit stage, mark all the inst's regs is > un_used. Every time , when one inst want to dispatch into the instQueue at > the dispatch stage, first check if this inst's dest reg is used or not. If > the destination reg is used, then means WAW/WAR, so block(tid). > > However, I have a question about how scoreboard works? I dump the new > scoreboard before and after dispatch stage to see what's going on with > scoreboard. For example, after inst_1 (pc 0000 for example) is dispatched, > then mark reg1 to used. And from the dump info, reg1 is indeed to be marked > as 1. Then before dispatch inst_2(pc 0004 for example), first check the new > scoreboard. However, from the dumped info, the reg1 is 0, which means it is > not used any more. I don't understand this because if the inst_2 is in > dispatch stage, then the inst_1 should be still in pipeline and reg1 should > still be used. So did I misunderstand something here? > > I really appreciate any hint. > > Thanks > > Xiangyang > > > On Mon, Jul 15, 2013 at 8:35 PM, Xiangyang Guo <[email protected]> wrote: > >> Hi, >> >> I got some problem, which I don't quite understand. I got the assertion >> problem, Assertion `indexInBounds(phys_reg)' failed. I print out the reg >> index, which is 1427. It of course is bigger than the regs I have in the >> system. But I do not understand why could I have a reg, which has a so >> large reg index. Also, from the running trace, I can see some info such as >> "7911000: system.cpu.rename: Adjusting reg index from 1427 to 125. " So >> could anyone help me explain this? Any hint is appreciable. >> >> Thanks a lot. >> >> >> On Mon, Jul 15, 2013 at 3:36 PM, Anthony Gutierrez <[email protected]>wrote: >> >>> I think if you want to try to get as close to an inorder approximation >>> as possible, using the O3 model, you should match the ROB size with the >>> issue width. It won't be 100% OoO, but it will get you close enough. Also, >>> make things like the LD/ST queues equal to the dispatch width as well. BP >>> sizes should be made much smaller. >>> >>> Anthony Gutierrez >>> http://web.eecs.umich.edu/~atgutier >>> >>> >>> On Mon, Jul 15, 2013 at 2:43 PM, Xiangyang Guo <[email protected]> wrote: >>> >>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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
