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]>:
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]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
