Review Board 2.0.15


CPU: Fix bug when a split transaction is issued to a faster cache

Review Request #304 - Created Nov. 11, 2010 and submitted

Information
Ali Saidi
gem5
Reviewers
Default 
CPU: Fix bug when a split transaction is issued to a faster cache

In the case of a split transaction and a cache that is faster than a CPU we
could get two responses before next_tick expires. Add an event that is
scheduled in this case and return false rather than asserting.

   

  


 


 

  

  









  
 


  

 


















 

  


 


  



   

   
Gabe Black

   
Posted  (Nov. 11, 2010, 9:20 a.m.)


  


  


  

   
This seems ok, although I won't claim to understand all of the possible interactions with other code. Is it possible for the tick event and the retry even to interfere with each other? Would their effect depend on the order they're handled?



  

   

   
    
    
   


  





  

 


  

 

















 



 

  


 


  



   

   
Steve Reinhardt

   
Posted  (Nov. 14, 2010, 11:53 p.m.)


  


  


  

   
If you knew the two parts coming back were halves of an unaligned access, it might be reasonable to try and combine them rather than forcing the second half to retry, but this seems OK to me.



  

   

   
    
    
   


  




   







    

     
     

      

       
        

         
          src/cpu/simple/timing.cc
          

           (Diff revision 1)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
need braces here around the if clause