Re: [Gems-users] Does gems (ruby) model the DMA operations now?

[Philip Garcia <pcgarcia@xxxxxxxx>]

I'm pretty sure the issue with DMA transactions is that they are not  
standard memory references as intercepted by simics.  I'm pretty sure  
the OS uses memory mapped I/O operations (which are ignored by simics)  
to setup a DMA transfer.  The DMA engine then operates, updating  
memory as it executes.  Ruby models the cache memory from the  
processors perspective.  The processor can issue load and store  
request to ruby, but there is no port for the DMA engine to use.    
Unless ruby intercepts commands from the OS to flush portions of the  
cache, I don't think Ruby has any way of knowing that the data was  
cached.   It is possible there's a simics exception or something that  
can be triggered when the OS flushes data from the cache, but I do not  
know for certain if this is the case.  However, traditional DMA  
requests are no different than any other hardware interactions.  If  
you did not write out a hardware model for it, it will default to  
simics models, which tend to be functionally accurate, but do not  
necessarily get timing correct.
Phil
On Dec 17, 2009, at 11:49 PM, Sitos Lin wrote:

> Hi:
>  Thank you for your reply. Maybe I can simplify my question. If there
> is a loop, in which a DMA operation fetches data from files to a
> predefined array with fixed size, does this loop incur a lot of cache
> misses every iteration? If the effect of DMAs is models, the loop
> should incur cache misses every iteration, because the data are not
> cached in the cache. However, if the effect of DMAs is not models,
> since the data of array (of their address) are in the cache, the
> memory accesses to these addresses may result in cache hits instead of
> cache misses. So, what situation would happen?
> Best regards,
>  Sitos
>
> 2009/12/18 Muhammad abid Mughal <mabidm_pieas@xxxxxxxxx>:
> > hi
> > I do know that Ruby does not support DMA requests even in gems-2.1.  
> > It just
> > filters them out via SimicsDriver::isunhandledtransaction(), so its  
> > not
> > possible for DMA requests to invalidate the corresponding cache  
> > blocks in
> > L1/L2 caches[i am wondering that DMA accesses I/O blocks and  
> > Ultrasparc
> > processor does not allow caching of i/o blocks, so no question of
> > invalidating corresponding L1$/L2$ blocks.am i right?]
> > Regards,
> > Muhammad abid
> > ________________________________
> > From: Sitos Lin <sitos.lin@xxxxxxxxx>
> > To: gems-users@xxxxxxxxxxx
> > Sent: Friday, December 18, 2009 11:24:41
> > Subject: [Gems-users] Does gems (ruby) model the DMA operations now?
> >
> > Hello all:
> >   I want to use gems (ruby) to capture the memory access trace.
> > However, I am wondering if gems models the DMA operations. In the
> > paper, it says "Also, Ruby does not model the memory system traffic
> > due to direct memory access (DMA) operations or memory-mapped I/O
> > loads and stores." However, gems is now version 2.1. Does gems model
> > the DMA operations now?
> >   Besides that, if the memory system traffic of DMA operations are  
> > not
> > modeled, I want to know if DMA operations invalidate the  
> > correspondent
> > cache blocks in L1/L2 caches. Since the values of memory have been
> > changed by DMA (read) operations, the cache blocks should be
> > invalidated and the following cache accesses to these lines should be
> > miss. I have tried to test gems by two simple program. However, the
> > results are not consistent to my knowledge. The program with
> > additional DMAs causes less cache misses than another one without DMA
> > operation.
> >   If gems can not model the features mentioned above, I will try  
> > other
> > approaches.
> > Best regards,
> >   Sitos
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding
> > "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> >
> >
> > ________________________________
> > New Email addresses available on Yahoo!
> > Get the Email name you've always wanted on the new @ymail and  
> > @rocketmail.
> > Hurry before someone else does!
> > _______________________________________________
> > Gems-users mailing list
> > Gems-users@xxxxxxxxxxx
> > https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> > Use Google to search the GEMS Users mailing list by adding
> > "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding  
> "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.