Thanks for the replies. I'm still trying to find my way around M5 and I thought the SE/TimingSimpleCPU would be a good way to see what's involved in modifying M5.
One thing that I'm worried about is that for this work, I have multiple memory operands in registers that need to be translated to physical addresses. In the SE mode, I've simply added a new fake Fault where it will translate all 3 addresses. However, I'm not sure if a similar approach would be possible in FS mode (I haven't looked at how any of the PAL stuff works). Do you think it would be more feasible to generate multiple single TLB faults per operand in the instruction, or to do something where they all get translated together using a new fault? On Thu, Feb 9, 2012 at 10:16 AM, Ali Saidi <[email protected]> wrote: > ** > > Hi Paul, > > > > Yes, in SE mode, it's just faked as a pipeline flush (in the simple CPU > model then pretty much nothing happens). It should be reasonably easy to > change the model to delay some number of ns on a TLB miss, but you'll get > the best results by running in fs mode. > > > > Ali > > > > On 09.02.2012 01:05, Paul Rosenfeld wrote: > > So do you think that my reasoning that the TLB miss penalty is simply a > single cycle re-fetch penalty on the faulting instruction is correct for > ALPHA_SE/TimingSimpleCPU? > > On Thu, Feb 9, 2012 at 12:31 AM, Gabriel Michael Black < > [email protected]> wrote: > >> I believe that's correct. >> >> >> Gabe >> >> Quoting Paul Rosenfeld <[email protected]>: >> >> I guess I forgot to mention in my original email that I was talking >>> about >>> alpha.... I think in FS it will vector into a PAL routine, but in SE it >>> looks like it's all just faked ... >>> >>> On Wed, Feb 8, 2012 at 11:08 PM, Gabriel Michael Black < >>> [email protected]> wrote: >>> >>> There are two types of mechanisms to handle TLB misses, in hardware >>>> or in >>>> software. If the ISA you're using does it in software, there's a fault >>>> which makes the OS handle the miss. In that case it will take however >>>> long >>>> it takes the OS to get things set up again. If the miss is handled in >>>> hardware, then there's a TLB walker component which does memory >>>> accesses to >>>> look up the entry in the page tables, and the delay is determined by >>>> those >>>> accesses. >>>> >>>> Gabe >>>> >>>> >>>> Quoting Paul Rosenfeld <[email protected]>: >>>> >>>> Hello all, >>>> >>>>> >>>>> I'm trying to modify the TLB code for SimpleTimingCPU, but one thing I >>>>> can't seem to find is what the latency of a DTLB miss is. I found the >>>>> code >>>>> in NDtbMissFault->invoke() for reading the page table mapping, but I >>>>> can't >>>>> seem to figure out if there's any mechanism for stalling the CPU to >>>>> handle >>>>> the fault. >>>>> >>>>> Reading the wiki for the SImpleTimingCPU, it sounds like it isn't >>>>> meant to >>>>> model this kind of detail. So is it just a one cycle fetch penalty for >>>>> handling a TLB miss? >>>>> >>>>> If this is the case, what's the simplest CPU model that will actually >>>>> stall >>>>> for TLB misses? >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>> ______________________________**_________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users<ht >>>> tp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users> >>>> >>>> >> >> _______________________________________________ >> 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
