Re: [Gems-users] hitcallback() question

[Greg Byrd <gbyrd@xxxxxxxx>]

I think you've discovered the "fast path" for accesses that hit in the 
first-level data cache.  They do not cause cache events, because they 
have no impact on the L2, interconnect, or memory controller.  This 
saves simulation time. 

This won't cause any data inconsistency, because Ruby doesn't 
read/modify data.  It only manages the state of the cache block and the 
timing of the request -- Simics reads/modifies data.

You can disable this (and simulate every access) by setting the Ruby 
parameter REMOVE_SINGLE_CYCLE_DCACHE_FAST_PATH to "true".
...Greg


May Zhao wrote:
> Hi ,
>
>        I met a problem about hitcallback() in Sequencer.C. I found there 
> are two functions will call hitcallback().
> One is sequencer.writeCallback() from "hh_load_hit" event in 
> MOSI_SMP_bcast-cache.sm.
> Another is makeRequest() from SimicsProcessor.C. The first one execute 
> cache coherence protocol through file
> MOSI_SMP_bcast-cache.sm. However, the second flow also modify the data block in
> L1Cache.
>       My question is what difference between these two functions lead to 
> hitcallback()? Why not all the requests will
> be processed by MOSI_SMP_bcast-cache.sm? Why some requests come from 
> SimicsProcessor.C to
> perform hitcallback()? I found the makeRequest() from SimicsProcessor.C may 
> cause the data inconsistency.
>       Thank you very much for any help.
>
> Regards,
> May
>
>   
>
> _______________________________________________
> 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.
>
>