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: - 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). - 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... Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
