Derin,
Here is my understanding of how Simics handles a TLB miss. This is based
on my observations of some traces I've gathered from Simics standalone,
NOT with Ruby, but my trace module uses the same interface that Ruby
uses. Specifically, I install the timing module on the physical memory
object, use a cycle-by-cycle callback, and also install haps for
core_exception and core_exception_return. At every cycle, I examine
Simics's PC -- whenever it changes I profile a new instruction. (I'm
using Simics 2.2.19)
Here is what I have noticed:
1) Calls to the exception hap handler I installed preceed any calls to
the timing interface for the excepting memory access.
2) The first time the excepting memory access is "executed", Simics does
*not* consult the timing interface to determine its data access timing.
3) The second time the excepting memory access is executed, i.e. after a
retry instruction, Simics provides an address to the timing interface.
Hence, I would expect your needs can be largely satisfied by installing
haps for core_exception and core_exception_return and manipulating flags
in Ruby in those handlers to ignore exception 0x68, a "fast" DTLB miss.
Regards,
Dan
mehmetderin.harmanci@xxxxxxx wrote:
Hello,
I have a question about how the exceptions/traps are managed by Simics+Ruby.
My main concern is to filter out (in Ruby) the TLB miss related address
requests arriving from Simics (I'm simulating another TLB and another TLB
miss handler which does not act on the same addresses as the Simics TLB/MMU).
But there is a subtle issue that I could not understand. I would appretiate
if anybody could help me on that issue.
I would explain what happens and what I do not understand in the story.
First of all, since I would like to filter out the TLB miss related
addresses arriving from Simics, I would like to avoid the repetition of
the faulting address due to the TLB miss. While I was trying to do this
I was confused which access of the faulting address (the one before the TLB
miss or after the TLB miss) I should filter out to carry out the cache
simulation for the faulting address as if it arrived only once and as if
there were no TLB misses.
My observation is as follows:
When the faulting address arrives it is first passed to Ruby by Simics and
Ruby starts handling it as if it is not faulting. After Ruby returns (here
what I mean by returning is giving the control to Simics and probably this
does not mean returning the latency due to that address to Simics), Simics
finds the TLB miss out and sends the TLB miss handler instruction address
to Ruby 1 cycle later (I think this happens independent of whether the
access is intruction or data access, but I'm not 100% sure).
The question is: If there were a miss with the faulting address would the
cache simulation be carried out for the fauting address or, the cache access
of the faulting address is somehow cancelled out or overriden by the arriving
TLB miss handling instruction access? Does this mean that for a faulting
address we will pass always 1 simics cycle before jumping to the TLB miss
handler and thus is it more suitable to filter out this access (the access
before TLB miss handler) of the faulting address for simulating its access to
the caches?
I was not sure if this is a message targetted to this forum or Simics forum
but I think the issue is more related to how Ruby interacts with Simics to
act on a TLB miss.
Any help for clarifying the issue will be appretiated.
Thanks,
Derin Harmanci
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}