Re: [Gems-users] flushing L1 caches

[Dan Gibson <degibson@xxxxxxxx>]

It looks like how I would implement the same functionality, though I don't know which dimension -- sets or assoc -- comes first in the m_cache member var -- maybe the indexes are backwards? (I haven't checked the definition)

Regards,
Dan

Mladen Nikitovic wrote:

Will do that. Thanks. Just wondered if there was anything semantically 
wrong with the code. I'm thinking about the way I've created the message 
and the way I've extracted the address from the cache. Does that seem as 
a reasonable approach?

I implemented the functions to extract the number of sets and ways and 
the address myself, there could be an error there. This is what I added 
to CacheMemory.h

template<class ENTRY>
inline
int CacheMemory<ENTRY>::getCacheNumSets()
{
  return m_cache_num_sets;
}

template<class ENTRY>
inline
int CacheMemory<ENTRY>::getCacheAssoc()
{
  return m_cache_assoc;
}

template<class ENTRY>
inline
Address CacheMemory<ENTRY>::getAddress(int i, int j)
{
  return m_cache[i][j].m_Address;
}

/M

Dan Gibson wrote:
  

This is a vector/array bounds assertion. Apparently some code in flush is 
accessing a Vector<L1Cache_Entry> with an offset too large for the specified 
size of the vector. As a first step, track down places were vectors are indexed 
in your call stack -- or better yet, attach gdb when you get the assertion and 
pop the call stack a few times to find the right spot.

Regards,
Dan

Mladen Nikitovic wrote:
    

I have reproduced the error and this is the message I get from 
Simics/GEMS when I try to do the flush:


simics> c
before flush (8023)
failed assertion 'index < m_size' at fn TYPE& Vector<TYPE>::ref(int) 
[with TYPE = L1Cache_Entry] in ../common/Vector.h:168
failed assertion 'index < m_size' at fn TYPE& Vector<TYPE>::ref(int) 
[with TYPE = L1Cache_Entry] in ../common/Vector.h:168
At this point you might want to attach a debug to the running and get to the
crash site; otherwise press enter to continue
PID: 3981
Warning: Interrupt key pressed more than once.
         Pressing it again will force Simics back to the command prompt.
         This may corrupt the running simulation.
         Try waiting for Simics to stop first.
USER INTERRUPT: Interrupt key pressed multiple times.
Returning to prompt.
simics>


Hopefully this can help someone to shed some light on this matter.

Best Regards,
Mladen

Mladen Nikitovic wrote:
  
      

Hi,

I'm trying to implement a function that flushes the L1 caches.  You can 
see from my previous posts that I have arrived at a solution that 
involves some augmentation of protocol code etc. But, the final thing is 
actually implementing the flush in the Sequencer, which was supposed to 
be done be walking the I and D-cache entries and sending invalidation 
request via the mandatory queue. I have tried to do that but the 
simulation crashes when I try call the flush at the point of shutting 
down one of the processors.

Implementation-wise, is there anything in the following function that 
should change?

Thanks.

Regards,
Mladen

void Sequencer::flushL1caches(int cpu)
{
  Time latency = SEQUENCER_TO_CONTROLLER_LATENCY;
  CacheMsg Imsg, Dmsg;
  int i,j, Iassoc, Dassoc, Isets, Dsets;

  Imsg.setType(CacheRequestType_INVALIDATE);
  Dmsg.setType(CacheRequestType_INVALIDATE);

  Isets = 
m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getCacheNumSets();
  Dsets = 
m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getCacheNumSets();

  Iassoc = 
m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getCacheAssoc();
  Dassoc = 
m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getCacheAssoc();

  for(i=0; i<Isets; i++) {
    for(j=0; i<Iassoc; j++) {
      
Imsg.setAddress(m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getAddress(i,j)); 

      m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(Imsg, 
latency);
    }
  }

  for(i=0; i<Dsets; i++) {
    for(j=0; i<Dassoc; j++) {
      
Dmsg.setAddress(m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getAddress(i,j)); 

      m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(Dmsg, 
latency);
    }
  }
}

_______________________________________________
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.


  
      

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!

  
------------------------------------------------------------------------

_______________________________________________
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.


  

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!