> On 2011-01-31 07:14:48, Steve Reinhardt wrote: > > I don't see why this is necessary. > > 1. I don't think caches request address ranges, they are just the default > > responder on buses where they sit on the memory-side of the bus. > > 2. As far as the timing issue, I don't know whether this diff makes things > > more realistic, but if timing is an issue then we ought to be able to just > > change the cache code to make it pass uncached accesses through more > > quickly. > > > > I don't think it's bad, necessarily, it just appears to be fixing something > > that I thought already worked, so if it's broken I'd like to understand > > better what the problem is before we commit to this being the fix. My > > apologies if I missed some previous email discussion; I've been bad about > > keeping up with m5-dev email lately. > > > > And why does it apply to x86 only? Is there something special about x86 > > that requires this?
I don't think 1 is correct. Caches request an address range, it just defaults to the whole address space. I'm guessing that's so you can set up banked caches. I implemented this because M5 wouldn't work without it because the none memory ports were conflicting with the cache address ranges. For 2, I wasn't talking about simulated time, I was talking mostly about simulated time. The uncached accesses would pass through unmolested (assuming there wasn't something with a transmission delay) but then you'd have to poke each cache, port interface, and intermediate bus on the way. This isn't really a big change, it's just making the config scripts route some ports through caches and some around them. I really doubt interrupt traffic on a real CPU goes through the cache, although I don't know that for a fact. The reason it's specific to x86, or really only came up now with x86, is that the CPUs in x86 have devices in them (interrupt controllers) that need to get messages from the devices (interrupt messages). No other ISA makes the CPU a target for packets, so no other ISA caused a conflict with the caches. This also cleans up some hackiness as far as how physmem_port was being handled, although it's possible that could have been eliminated regardless. - Gabe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/455/#review825 ----------------------------------------------------------- On 2011-01-29 15:12:55, Gabe Black wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/455/ > ----------------------------------------------------------- > > (Updated 2011-01-29 15:12:55) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > Config: Keep track of uncached and cached ports separately. > > This makes sure that the address ranges requested for caches and uncached > ports > don't conflict with each other, and that accesses which are always uncached > (message signaled interrupts for instance) don't waste time passing through > caches. > > > Diffs > ----- > > src/cpu/inorder/InOrderCPU.py 31a04e5ac4be > src/cpu/o3/O3CPU.py 31a04e5ac4be > src/cpu/BaseCPU.py 31a04e5ac4be > configs/common/CacheConfig.py 31a04e5ac4be > configs/example/fs.py 31a04e5ac4be > configs/splash2/run.py 31a04e5ac4be > src/cpu/simple/AtomicSimpleCPU.py 31a04e5ac4be > src/cpu/simple/TimingSimpleCPU.py 31a04e5ac4be > tests/configs/inorder-timing.py 31a04e5ac4be > tests/configs/o3-timing-mp-ruby.py 31a04e5ac4be > tests/configs/o3-timing-mp.py 31a04e5ac4be > tests/configs/o3-timing-ruby.py 31a04e5ac4be > tests/configs/o3-timing.py 31a04e5ac4be > tests/configs/realview-simple-atomic.py 31a04e5ac4be > tests/configs/realview-simple-timing.py 31a04e5ac4be > tests/configs/simple-atomic-mp-ruby.py 31a04e5ac4be > tests/configs/simple-atomic-mp.py 31a04e5ac4be > tests/configs/simple-atomic.py 31a04e5ac4be > tests/configs/simple-timing-mp.py 31a04e5ac4be > tests/configs/simple-timing.py 31a04e5ac4be > tests/configs/t1000-simple-atomic.py 31a04e5ac4be > tests/configs/tsunami-o3-dual.py 31a04e5ac4be > tests/configs/tsunami-o3.py 31a04e5ac4be > tests/configs/tsunami-simple-atomic-dual.py 31a04e5ac4be > tests/configs/tsunami-simple-atomic.py 31a04e5ac4be > tests/configs/tsunami-simple-timing-dual.py 31a04e5ac4be > tests/configs/tsunami-simple-timing.py 31a04e5ac4be > tests/configs/twosys-tsunami-simple-atomic.py 31a04e5ac4be > > Diff: http://reviews.m5sim.org/r/455/diff > > > Testing > ------- > > > Thanks, > > Gabe > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
