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
