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
