Quoting Ali Saidi <[email protected]>:
On Wed, 14 Dec 2011 22:24:37 -0000, "Ali Saidi" <[email protected]> wrote:
On 2011-12-13 13:35:40, Geoffrey Blake wrote:
Cleaned up the code in base_dyn_inst.hh to use templates.
Cleaned up the code in arch/arm/isa.cc to get the ITB/DTB
pointers from the CheckerCPU object.
I have implemented a solution for functional accesses that go to
the IOBus by adding a "reflect_functional_access" parameter to
isa_fake.cc. This parameter allows accesses to pass through if
they are detected to be functional via checking if the Packet
object can be safely cast to a FunctionalPacket object to
identify just functional accesses. I then added this io_device
with the reflect param set to the IOBus as a default responder
for the ARM setup in configs/common/FSConfig.py. Not sure if
this is what is ultimately desired, but it fixes the problem with
the Checker's functional accesses without the hack in the bus.cc
code. I looked at using the default_range variable as Steve
suggested, but saw in bus.cc line 359 that the code would panic
if the access did not fit in the default range. Also would like
some suggestions as to how to warn on detecting no default
responder attached to the IOBus (any bus), should it be in the
Python or C++ code?
This solution doesn't work if you've got a PCI config space device
attached as the default responder for a certain range on the I/O bus.
In this case you'll hit the panic that Geoff described.
Every solution i've come up with seems to fail however, e.g.:
You could say if a cache is top_level then don't forward it on, but
this would prevent snooping into an lsq or something similar.
The best I can come up with is that you want to change findPort() to
say if this is a request based on a recvFunctional() then return a
NO_PORT if a destination isn't found rather than panicing and if
NO_PORT is returned then don't call port->sendFunctional() and just do
the snoop.
thoughts?
bump.
Ali
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
Sorry, I've been busy/lazy lately. I'll try to look at it this
weekend, but we have some family things both days. I do intend to look
at it soonish.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
