Brad,
I don't recall if talked about the following situtation on Tuesday --
suppose we have a functional access for an address A. Further assume that
the corresponding cache block is in base state in all the caches (if
present). But there is timing access to this block which is currently in
some message buffer, or the request has not been yet issued due to lack of
resources.
Current implementation of functional accesses takes in to account the
timing accesses that are inflight (refer to the function checkFunctional()
in src/mem/packet.cc).
I think, if do add code to detect such cases, then we should return that
the functional access failed. Consider the case when two timing accesses
to same address (both are writes) are inflight and there is a functional
read access to that address. In this case, we would not be able to decide
which value to return for the read.
Nilay
On Fri, 25 Feb 2011, Beckmann, Brad wrote:
Yes, that is correct. The RubyPort::M5Port::recvFunctional() function is where
we need to add the new support.
Brad
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Nilay Vaish
Sent: Friday, February 25, 2011 12:20 PM
To: [email protected]
Subject: [m5-dev] Functional Access support in Ruby
Brad,
Here is my understanding of the current state of functional accesses in gem5.
As of now, all functional accesses are forwarded to the PhysicalMemory's
MemoryPort. Instead, we would like to add
recvFunctional() function to M5Port of the RubyPort, and attach this port as
peer instead of the PhysicalMemory.
--
Nilay
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
