My suggestion would be to set up the configuration so that you have a normal MemTester object hooked up to the DMA port... it doesn't need to know that it's emulating a DMA device rather than a CPU. I don't know if that's feasible or not, or worth doing now that you've made these modifications already, but it should avoid needing any changes at all to the packet or request classes or to memtester.cc, I think.
Steve On Tue, Sep 1, 2009 at 8:52 AM, Polina Dudnik<[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, but I think we >> should discuss whether that's the right thing for Ruby to be doing >> before we move ahead with exposing it in the port/request interface. >> If we need to manage it temporarily as a transition thing then there >> might be less invasive ways of doing it. >> > > You are right that DMA port does not have to be very specialized. Ideally, > rubymem.cc will getPort without passing a name, but simply get all the ports > specified in the config file. As for requests, they are not particularly > specialized. There's simply a DMA flag. Based on the flag, the request is > either submitted to the DMA port or a normal L1 port. In the context of the > cpu model (as opposed to the tester), the requests can be automatically > forwarded to the DMA requests because the entity making the request will set > the correct contextId in the packet. I just went with the simpler way of > letting pseudo-cpus in the tester also issue DMA requests. > > I agree that this is not ideal, so I can just keep these proposed changes > local. > >> >> Polina, the fixes you have to src/cpu/memtest/SConscript are needed >> and are independent of DMA testing, so please commit and push just >> that file as a separate changeset. (Since it is unrelated, I would >> suggest committing it separately even if we were going to go ahead >> with the DMA changes.) >> > > Done. > >> >> Also, on a minor note: I don't know that we have a rule about this, >> but I'm generally opposed to putting names or initials in comments, >> since (1) these accumulate over time and clutter the comments and (2) >> the source code control system makes it relatively easy to figure out >> who to blame for a particular change (e.g., 'hg annotate'). >> > > Noted. > > >> >> Thanks, >> >> Steve >> >> On Tue, Sep 1, 2009 at 7:43 AM, Polina Dudnik<[email protected]> wrote: >> > Hi, >> > >> > I am attaching a patch that allows memtest.cc to issue DMA requests. >> > >> > The changes include: >> > >> > 1. Add bool use_dma and percent_dma to MemTest.py >> > 2. Fix if O3CPU SCons issue that Somayeh had >> > 3. Add percent_dma and use_dma to memtest.hh and memtest.cc >> > 4. Added generation of dma requests to memtest.cc >> > 5. Add DMA_REQUEST flag to request.hh >> > 6. Replaced assert with return -1 if DMASequencer is bucy >> > 7. Added DMA port in rubymem.cc >> > 8. Added DMA request handling in rubymem.cc >> > >> > Polina >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
