Hi gem5 users, I am trying to implement something similar to "slip-stream" or "dual-core execution" kind of architectures -- though not the same ideas. Those who are unfamiliar with these architecture here are the references: http://iacoma.cs.uiuc.edu/CS497/SP4.pdf http://pact05.ce.ucsc.edu/dce.pdf
In such systems, we have basically two cores. One is main core and other is speculative run-ahead core that runs ahead and passed execution based branch hints to main core. It also prefetches in the shared L2 cache but never writes to it. I think I can derive the two kind of cores from already implemented O3CPU class. However, I have to implement a "branch output queue" that I did by adding a new SimObject named as "BOQUnit" similar to a FIFO queue. However, the bigger issue is how to modify the fetch, execute, IEW, and commit stages. I think these changes needs to be done in order to implement the dual-core execution idea. Fetch stage: ========= Run-ahead core: No modification Main core: Instead of getting the branch-predictions from the branch predictor we need to get it from the BOQUnit. Concerned file is fetch_impl.hh in ~/cpu/o3 and the function is *DefaultFetch<Impl>::lookupAndUpdateNextPC(DynInstPtr &inst, TheISA::PCState &nextPC)predict_taken = branchPred->predict(inst->staticInst, inst->seqNum, nextPC, tid);* The second function needs to recognize whether it the fetch of run-ahead core or regular core.However, depending upon whether it is run-ahead core or main-core it has to draw predictions from either BOQ or Branch Predictor. Execute stage: ============= Run-ahead core: Deposit the branch outcome to BOQ Main core: No modification Commit Stage: ============ Run-ahead core: No modification Main core: Check the run-ahead branch outcome with "actual" branch outcome of main core. If the run-ahead prediction (BOQ entry) was wrong then synchronize both the core. To me it looks like I have to modify the internals of Fetch, Commit and IEW stages. Just deriving a class from O3CPU class and adding few functions will not be sufficient. Am I right? Also if that is true, then any thoughts about implementing the whole idea with minimal modifications to the baseline code. I like the current implementation of gem5 and don't want to litter it with my ad-hoc solutions. Something that is seamless to integrate would have more value. Thanks, -Raj Parihar University of Rochester, NY
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
