> That's not what I mean. What I'm saying is, simulate the timing of a > TLB stage, but do the functional access with the memory stage. I.e. > split it for timing purposes, but leave it together for functional > reasons. I'd be surprised if this does not work since the timing of > TLB accesses at that granularity shouldn't have much of an impact on > the program. I think Steve agreed with me on this one. (right Steve?)
Yea, I think we are misunderstanding each other here. I guess I'm not exactly sure what you are getting at or what point you are arguing for (since the conversation got restarted again I may be lost in translation) For your point about TLB accesses and timing, I thought that we had resolved that the timing of TLBs does have a impact on the program which is why Gabe went through making a "translateTiming" access for the TLB and then also making SE mode use a TLB. Also, I figure that if there are situations where you dont want to use the TLB then it makes sense to not continously access the TLB object. And then lastly, in situations where you have a a situation of a # of dependent memory accesses waiting, it might be better for them to translate early if there is going to possibly be a time associated with a TLB miss/hit (situation that gets exacerbated with more threads on 1 CPU I would assume)... So thats why currently I have instructions being having to request the TLB and the Cache as separate entities and which forced me to add "getMemFlags" and "memAccSize" to the Instruction. That implementation I have now works well but potentially there's a better non-intrusive solution to the instruction object. Or it sounds like people want to just X out that functionality and always force a memory access to be tied to a TLB access on that same cycle. > > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
