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
