Hi Polina, Sorry for the delayed reply. You're right that in general I don't think there should be any first-order distinction between DMA devices and CPUs. M5 doesn't have and hasn't needed this distinction. If I understand Derek's earlier email correctly, Ruby doesn't fundamentally have this distinction either, which is good. It sounds like the distinction comes in only in the way Ruby is configured for Bochs, which is fine. I don't know enough about Bochs to say, but it seems reasonable for that to be the case. Certainly once you start configuring particular systems in M5, some of them will be CPUs and some will be DMA devices, and if the configuration itself depends on that distinction, that's OK.
The main thing I'm trying to prevent is having this configuration-level Bochs-specific distinction seep down into the core of M5, which is what's happening when you add the DMA_REQUEST flag to the M5 Request type. If it's just a matter of needing a MemTester object to inject requests into the port connected to the DMA Sequencer, from my perspective the easy thing to do is to just instantiate another MemTester and connect it to that port. I think you're agreeing below that that would work. Then the only changes would be in the test configuration. I don't see a need to change MemTester at all, but I may be missing something... let me know if that's the case. Another question I have is whether the DMA Sequencer really does anything different from a CPU Sequencer, and what set of Ruby memory configurations should be added to the regression test. Note that the code in the tests directory is really only for regression tests, i.e., things we want to run regularly and automatically and verify that the detailed statistics have not changed. Certainly when I was working on the M5 coherence protocol I ran far more tests (longer and more varied) with MemTester than the one simple instance that's in the regressions. I'm not clear on whether you're just trying to set up a test for the DMA Sequencer for debugging purposes (which should be an easy change to a config script somewhere) or trying to set up a test to include in the regressions (which we generally only do once that test is working outside the regressions). Steve On Tue, Sep 1, 2009 at 3:37 PM, Polina Dudnik<[email protected]> wrote: > Steve, > > I just want to finish this discussion so that I know what to do. > > Just to backtrack a little (and I am sure you know this all): DMA is handled > in Ruby by a separate sequencer called DMASequencer and a separate coherence > protocol object. When DMA requests are issued they have to be sent to > DMASequencer. So, in the tester for me to make DMA requests I need access to > DMA port. > > I tried to stick with what was done to get Sequencer ports. Specifically, > right now when memtest is called, python scripts create RubyMemory object. > When RubyMemory object is created, for every CPU in the system, the ports > are pushed into a vector. What I did is I just added a DMA port to that too. > DMA is created regardless of whether or not I add the port because the .rb > configuration file has one. So, all I did is just made it visible, so I > could access it with the tester. > > Normally, the DMA requests will be forwarded to DMA port just based on the > fact that they are coming not from CPU's but from IO devices. In the tester > what I could have done, is in addition to emulating cpu objects also emulate > io devices. That way I would not need DMA_REQUEST flag. So I could do that. > What this will do is get rid of the DMA_FLAG that I added. > > > What I could also do is get rid of pushing back the dma port and instead > just get it before issuing a dma request in the tester. That way, all the > changes to test dma requests will be just in the tester. > > But, if I understand correctly, you are more concerned with having DMA > separate. Not just in the tester, but in general. Because DMA was made into > it's own object in the coherence protocol, I don't see a good way around > that. > > Polina > > > On Tue, Sep 1, 2009 at 11:35 AM, Polina Dudnik <[email protected]> wrote: >> >> >> On Tue, Sep 1, 2009 at 11:16 AM, Steve Reinhardt <[email protected]> wrote: >>> >>> On Tue, Sep 1, 2009 at 9:09 AM, Derek Hower<[email protected]> wrote: >>> > On Tue, Sep 1, 2009 at 10:29 AM, Steve Reinhardt<[email protected]> >>> > wrote: >>> >> Before we worry about the details of this patch, I have a higher-level >>> >> question: why do we need a separate DMA request type and port at all? >>> >> On the M5 side, we've gotten by just fine so far with ReadReq and >>> >> WriteReq, and M5 devices don't explicitly mark their DMA requests as >>> >> such. I understand that that's how Ruby does things, >>> > >>> > That's only partially true. Ruby doesn't actually make a distinction >>> > between DMA and CPU ports. Both are abstract RubyPort objects and >>> > take the same read/write request types. The only time they are >>> > distinguished is in the configuration system when the ports are >>> > matched up to their corresponding objects in Bochs. >>> >>> Excellent... even more reason to just handle it in some Bochs-specific >>> config script and not put any dedicated support in the C++. >>> >> >> Steve, I must be confused, but I don't quite understand how you envision >> bochs-specific >> config scripts handling port assignment for the m5 tester. >> >> Polina >> >>> >>> Steve >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >> > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
