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/
|
|