You're right that the Alpha TLB doesn't take advantage of that, but it could be modified to. You can use either the ARM or X86 TLBs as an example. It will be simpler than those since it doesn't actually access memory to fix up mappings. You probably want to maintain state based on a particular translation rather than the request object. You won't have to change the CPU or change how it works (for example, issue multiple fetches) to get it to handle delayed translations, it should just work if the TLB supports it properly.
Gabe On 10/21/11 12:19, Jiachen Xue wrote: > Hi Gabriel, > > Thanks very much for your reply. > > Unfortunately, I am using ALPHA which does not have the support for > delayed translation. I am just wondering, is it possible not to make > TLB having its own timing, events etc? I am thinking letting each > "mem_req" has its own state, like you said, if it is a hit in the > first half of the TLB, it proceeds, and if it is a miss, update the > state machine inside the "mem_req" and redo the fetch for the second > half of the TLB. Of course the TLB would direct the search to > different halves based on the state of the "mem_req". > > Thanks, > > On Fri, Oct 21, 2011 at 1:43 AM, Gabriel Michael Black > <[email protected] <mailto:[email protected]>> wrote: > > The TLBs and CPUs have support for delaying the completion of > translation. You'd want to delay all the time, and if you're using > an ISA that already does this (Arm or X86) then you'd decide > whether to delay based on the TLB access latency in the case of a > hit, or waiting for memory in the case of a miss. You'd > essentially be making the TLB more like a device with an internal > state machine, timing, and events. > > Gabe > > > Quoting Jiachen Xue <[email protected] <mailto:[email protected]>>: > > Hi, > > My situation is that I am increasing the size of TLB so that > the access to > TLB will not fit into one cycle. Say, the TLB can be divided > into two parts, > each part can be accessed within one cycle. The lookup process > now becomes > as follows: > > 1. If fetch hits in the first half, proceed as normals. > 2. If miss in the first half, now I need to look into the > second half. > > If I need to look into the second half, from what I > understand, I need to > schedule a new fetch event in the next cycle. So, is it > correct to add > something like: > > cpu->schedule(finishTranslationEvent, cpu->nextCycle(curTick() + > cpu->ticks(1))) > > as appeared in line 745 in cpu/o3/fetch_impl.hh. > > Thanks, > > -- > Sincerely, > Jiachen Xue > > > > _______________________________________________ > gem5-users mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > > -- > Sincerely, > Jiachen Xue > > > _______________________________________________ > 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
