Thanks Derek. I think we should be consistent with how GEMS separates sequencer requests from network requests and thus we should split them into two different types. The DMA network requests should be specified in the protocol message file since they interact with that particular protocol's state machines. However, the DMA sequencer messages need to be in Ruby_Exports because the DMA sequencer lives on the Ruby side. That should work well with Steve's suggestion to use byte addresses and lengths.
I'll reply to the other issues on separate threads. Brad -----Original Message----- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Derek Hower Sent: Monday, August 03, 2009 1:03 PM To: M5 Developer List Subject: Re: [m5-dev] Fwd: GEM5 Issues On Mon, Aug 3, 2009 at 2:49 PM, Steve Reinhardt<ste...@gmail.com> wrote: > On Mon, Aug 3, 2009 at 11:16 AM, Derek Hower<derek.ho...@gmail.com> wrote: >> >> I do like the idea of a generic SequencerMsg class, but am a little >> worried that it would ultimately be confusing. We can certianly split >> DMARequestMsg into two different types, one for the request to the DMA >> sequencer and one for the request to the network, like CacheMsg and >> RequestMsg. In fact, this is probably the right thing to do to get rid >> of the DMA assumption. The request to the DMA Sequencer wouldn't look >> exactly like a CacheMsg, though, because it needs an Offset and Len >> field to account for block-unaligned accesses. (The cache Sequencer >> doesn't need these because it updates data locally after a request >> completes and handles alignment then. The DMA controller doesn't have >> that luxury because the update happens at memory, not in the DMA >> itself, and so it must propagate those fields to the protocol). Thus, >> a generic SequencerMsg would have to have Offset and Len fields as >> well, even though they wouldn't be used by the cache Sequencer. The >> cache Sequencer *could* use those fields if it let the protocol do the >> data update, but that would require changing all the protocols. The >> change would be very minor, though. Make sense? > > Just for reference, the current M5 memory system solves these issues > as follows--not that it's the best way to do it, but I'd be curious > about the motivation (other than history/inertia) for Ruby to do it > differently: A lot of Ruby is inertia :) > > - All requests have a byte address and a length. Cache coherence > messages all set the length to the block size, and insure/assert that > the offset bits of the byte address are zero (or possibly ignore > them). It's necessary for caches to be able to generate requests with > unaligned addresses and other lengths for when they forward > uncacheable requests between CPUs and memory/devices. Having separate > block number and offset fields is functionally equivalent, but seems > slightly more awkward to me, and would probably make your struct a > little bigger (not huge, but every little bit helps). Good point. > > - A system configuration with coherent caches needs to have a cache > between any DMA devices and the rest of the memory system to translate > partial-block DMA writes into coherent requests. When you say "the > update happens at memory" for DMA, does this mean that the memory > controller is responsible for the coherence side effects, e.g., > invalidating other cached copies and potentially merging partial block > writes with outstanding modified copies? Or are these side effects > not modeled? Note that the latter is OK for a stopgap but > unacceptable long term for us... Yes, the directory handles the side effects. Here's the sequence for a DMA write: 1. DMA Controller issues DMA_WRITE request to directory 2. Directory invalidates sharers/owner if needed 3. Directory updates the data 4. Directory writes to DRAM. 5. Directory sends Ack to DMA The DMA controller never sees the original copy of the data, so can't do the merge itself on a partial write. > > Steve > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
