Hey guys,
  I just updated my repo to the gem5 head, and I'm trying to merge my old
patches.  It looks like the TranslatingPort that used to be the O3CPU
funcport has changed, and I run into a fatal when trying to run the new
code.

  I'm trying to run simulation with x86 O3CPU, full_system=False (SE mode),
and using a Ruby cache hierarchy.  With the old code, the O3CPU would
simply use the funcport (before the FS/SE merge) to read from the physmem
directly (::aside:: this already confuses me, since if the data is modified
in a cache, shouldn't that data be read?).  With the updated gem5 code, the
functional access uses the O3CPU's data port, which is connected to a Ruby
sequencer (more as I would expect), which checks to see if the data is in a
cache before grabbing the data for the read.

  The problem that I'm running into is in RubyPort.cc: When the functional
read gets to the cache hierarchy, Ruby finds that the AccessPermission on
the data it's looking for is in the Busy state (in
RubyPort::M5Port::doFunctionalRead(PacketPtr pkt) the num_busy value is 2
since the data is currently in the process of being transferred up the
cache hierarchy in a timing request).  Because it's in the busy state,
doFunctionalRead returns false, which
causes RubyPort::M5Port::recvFunctional to fall into the if-statement
checking if the access failed (line 445).

  In this case, couldn't the functional read just grab the data from
memory?  If so, shouldn't there be better signalling between the
doFunctional<type> functions and recvFunctional in RubyPort::M5Port to
indicate the access permissions on the data?  Suggestions on how this might
be fixed?

  Thanks!
  Joel

-- 
  Joel Hestness
  PhD Student, Computer Architecture
  Dept. of Computer Science, University of Texas - Austin
  http://www.cs.utexas.edu/~hestness
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to