Hi all,
My aim is to introduce a fault in the cache coherence model, wherein a
request from a particular core is mishandled causing some observable change
in the statistics when the simulated system is tested on some benchmarks (
Splash2 benchmarks ). For Example when a cache miss occurs for read request
from core 0, instead of sending GetS to directory, a new cache block is
allocated and null data is return as loadHit.
My doubts :
Q.) How is core represented in the code ?
>From my understanding, in sequencer.cc we have 3 variables, proc_id,
core_id and m_version.
>From learninggem5.org, in "debugging slicc protocol" we have m_version as
the core from which request has arrived. In the file "RubyPort.cc",
m_version gets initialized to p->version, p being some parameter passed to
it.
core_id should be the core id of the request, which when printed using
debug flags and ruby random testers shows 99 for all requests, which I
don't understand why
proc_id should be the processor id, which shows equal to m_version
So I have the following question with regard to this ?
1.) What is processor id, why its equal to m_version always ? ( If we
assume there's one core per processor, then how can we model multiple core
single processor system )
2.) By modifying the RubyRequest I have successfully brought the proc_id
(which I assume to be the core sending request) in the slicc interface. Now
on modifying MSI-cache.sm, by introducing an event FLoad, wherin all load
request from core 0, will have the following transition
transistion(I, Fload, S)
{
allocateCacheBlock;
loadHit;
popMandatoryQueue;
}
I should have got incorrect results or some change in stats.txt file when
running the FFT/FMM Benchmarks. But I didn't get any
I have been stuck with this conceptual or implementation problem since a
long time and trying my best to solve this. Any help would be really
appreciated
Regards,
Arka
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
