Re: [Gems-users] Bypass L1 cache?


Date: Thu, 12 May 2011 10:43:51 -0500
From: Venkatanathan Varadarajan <venkatv@xxxxxxxxxxx>
Subject: Re: [Gems-users] Bypass L1 cache?
Even if the access to the L2 is always going to be a hit (by design of whatever you are doing) it is not a good idea to use tryCacheAccess() method of the cache memory.

Reason: tryCacheAccess() is going to return a hit if it is available in the cache at that instant when the method is called (it need not be the case that a miss when you do a tryCacheAccess() it is a miss in L2 cache - it is the way ruby (Sequencer) is implemented)

As far as I know, what ever needs to be sent to the L2 (any request) needs to go through L1 (through the slicc interface). There are work around that might require changes to the slicc protocol definition.

Overall, I think you might need to get your hands dirty by diving into slicc (I am not sure if there is another way of dealing with this, correct me if I am wrong).

The declarations are the ones that are generated by the slicc code. These objects model the cache memory.

Regards,
Venkat

On 05/11/2011 09:33 PM, Binh Q. Pham wrote:
Hi Venkat,
Thanks for a fast response. Do you know what these declarations mean?
// pulic data structures
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_L1DcacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_L1IcacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_cacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_L2cacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L2Cache_L2cacheMemory_vec;


About what I want to do: for a certain physical address, I don't want to use it to access L1 cache; instead I want to go to L2 cache directly.

Binh

On 05/11/2011 12:32 PM, Venkatanathan Varadarajan wrote:
The answer to your question depends more on what you are going to by pass (is it in the protocol level or just direct access to data present in L2)?

The memory subsystem simulated by ruby is very much tied to the slicc interface (starting from L1, the control is taken over by the slicc interface (the slicc generated code) from the system/Sequencer).

-Venkat
On 05/11/2011 11:07 AM, Binh Q. Pham wrote:
Hi,
In ruby/slicc_interface/AbstractChip.h, I saw the following declaration:
// pulic data structures
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_L1DcacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_L1IcacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_cacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L1Cache_L2cacheMemory_vec;
  Vector < CacheMemory<L1Cache_Entry>* > m_L2Cache_L2cacheMemory_vec;

For the first two declarations, I guess they are L1 data cache and L1 instruction cache respectively. However, I don't understand the other three declarations. Does anyone know what is going on here?My goal is to bypass L1 cache for a certain request, and pass it directly to L2 cache. I am thinking I can call the function tryCacheAccess in ruby/system/Sequencer.C on a L2 cache object to do this. Am I on the right track here?
Thank you,
Binh
_______________________________________________ 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.


-- 
Venkatanathan Varadarajan,
Graduate Student,
Department of Computer Sciences,
University of Wisconsin - Madison.
http://pages.cs.wisc.edu/~venkatv/
_______________________________________________ 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.


-- 
Venkatanathan Varadarajan,
Graduate Student,
Department of Computer Sciences,
University of Wisconsin - Madison.
http://pages.cs.wisc.edu/~venkatv/
[← Prev in Thread] Current Thread [Next in Thread→]