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
