Hi, Ashish, Thanks for reply. Yes, I also think the reason is I didn't make the all reg ready after one inst finished. I just change the dependent graph to use one graph to indicate all the WAW WAR and RAW, so maybe I need to separate to 3 dep_graph. Thanks
Regards Xiangyang On Sun, Jul 14, 2013 at 6:02 PM, Ashish Venkat <[email protected]> wrote: > Hi Xiangyang, > > When I modified the O3 processor to inorder, I used 3 separate dependency > graphs to check for RAW, WAR and WAW, and stall an instruction until all > source and destination registers are ready. You can use a similar function > to markSrcRegReady for making a destination register ready at any > particular stage of the pipeline, and consequently wake dependents from the > respective graphs. Also, you might want to issue instructions based on the > sequence number ordering instead of reducing the issue width to 1. That > gives you more flexibility. > > There are a number of reasons why you might run into deadlock (or result > in inaccurate execution). But it is almost always because you don't mark a > source/destination register ready due to a false dependency. Note that you > also need to handle the squash path in addition to the commit path. I am > not sure if there is a better way to debug this. But writing a cycle > accurate pipeline diagram by hand, and then matching it with the O3CPUAll > trace worked well for me. > > Hope that helps! > > -Ashish > — > Sent via Carrier Pigeon > > > On Sun, Jul 14, 2013 at 11:54 AM, 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
