[Gems-users] GEMS TLB Operation

["Abhishek Bhattacharjee" <bhattacharjee.abhishek@xxxxxxxxx>]

Hi all -

This is a follow-up to my previous post on TLB modeling in GEMS. Based on the code, I believe the TLB operation is as follows:
Simics manages the hardware TLBs internally. The sizes, associativity etc. are all specified here directly. It seems that Opal is used to request translations from Simics for both instruction and data acesses whenever desired. For the instruction fetch, translation appears to happen in the function

void pseq_t::lookupInstruction() in pseq.C

Here, the following is used to poll Simics to find whether the translation is in the TLB

inTLB = getInstr(apc->pc, apc->tl, apc->pstate, fetchPhysicalPC_ptr, &next_instr, proc);

At this point, I am looking to collect statistics on the particular address translations that cause TLB misses. Therefore, I have added the following to the lookupInstruction(  ) function:

if ( !inTLB)  {
       
             fprintf(stderr, "ITLB Miss CPU %d \t Cycle %d \t Virtual Address %llx \t \n", m_id, getLocalCycle(), apc->pc);

    ...
}


It appears that this is sufficient to extract the TLB misses and the relevant translations causing this. My first question is just a check: are my assumptions about the above correct? Does it look like I am on the right track?

The second question I have is about the specific address translations causing Instruction TLB misses. Based on the information I am printing out in the lookupInstruction (  ) function, I am seeing a rather curious behavior in terms of addresses causing TLB misses. There are a high number of times that a CPU appears to request a translation for virtual address 0, prompting a TLB miss. First, I am a little unsure why this address repeats so often; second, if this translation does occur this often, why isn't it cached in the TLB? I printed out the ASI for this translation and it appears to be 0x80 which should be cached in the TLB. I must be missing something here...

Any feedback would be highly appreciated!
Abhishek

I