Review Board 2.0.15


Let the user execute a file just before 'Simulation.run'

Review Request #1455 - Created Sept. 28, 2012 and updated

Information
Lluís Vilanova
gem5
Reviewers
Default 
Let the user execute a file just before 'Simulation.run'.

This file can be used, for example, to set parameters that are not available through the command-line options.

Patch was applied on top of latest development version, so I don't understand how this can fail (my previous patches in the MQ do not touch Options.py).


   

  


 


 

  

  






 
 
Issue Summary

 

  

   
    
    1
   
   
    
    1
   
   
    
    0
   
   
    
    0
   
  

  

   

    
    
   

   

    
    
   

  

 

 

  

   
    

     Description
     From
     Last Updated
     Status
    

   
   



































    

     Should this be 'testsys' not 'test_sys'?
     Steve Reinhardt
     Jan. 7, 2013, 3:08 a.m.
     Open
    


















   
  

 









  
 


  

 













 



 













 



 


















 













 



 













 



 

  


 

  

   

   
Review request changed

   
Updated  (Oct. 23, 2012, 4:22 a.m.)

  

  




   
Change Summary:

   
Rebase on r9308 and move "post-script" invocation into "Simulation.run", just before "m5.instantiate".





   



    

     
Diff:

     
      
 Revision 3 (+12)
Show changes
 
    configs/common/Options.py 
    configs/common/Simulation.py 
 

     		
    



   




  

 


  

 



















 

  


 


  




   
Ship it!



   

   
Ali Saidi

   
Posted  (Jan. 7, 2013, 2:58 a.m.)


  


  


  

   
this seems fine to me, anyone else have some input?




  

   

   
    
    
   


  





  

 


  

 



















 

  


 


  



   

   
Steve Reinhardt

   
Posted  (Jan. 7, 2013, 3:08 a.m.)


  


  


  

   
In general I would prefer an approach where unique simulation requirements were handled by a unique top-level script; originally files like se.py were intended merely to be examples that would be customized as needed (hence the directory name "configs/example").  If the configuration code were a bit more modular, such that those example files were only a handful of lines of code (not 100+), I would push harder to keep that vision.  If I'm the only one that feels that way, though, I won't oppose this.



  

   

   
    
    
   


  




   







    

     
     

      

       
        

         
          configs/common/Simulation.py
          

           (Diff revision 3)

          
         
        

       
       
        
 


        
 


       
      

     

    

    


     
Should this be 'testsys' not 'test_sys'?


     





 

  
  
  
  
  
  Show all issues
 




     




  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    This is actually intended as a quick hack that stands between the current code and an ad-hoc frontend implementation (e.g., I used it to monkey patch some simple simulation parameters like ROB and PRF size, or the path to the secondary HHDD image on top of fs.py).

But I completely agree that in the long run all the python code in the frontends should be properly modularized and parametrized, although that would require some broader changes and much more time than my patch took me :)

And yes, it should be "testsys"; can you please fix it for me when (if) committing? Thanks
    
    
    
   
    2. 

   


  


    


   



  

 


  

 

















 



 

  


 


  



   

   
Andreas Sandberg

   
Posted  (Jan. 7, 2013, 4:44 a.m.)


  


  


  

   
I agree with Steve. I'm not at all a fan of adding more cruft to the simulation scripts. It's almost impossible to understand them already. What we really ought to do is to rewrite them and to make them simpler to reuse and customize instead of trying to do everything in the example configuration.



  

   

   
    
    

   
  1. 
    
    
     
    
      
     
    
     
    I think something closer to the ideal would be to split system configuration into a few programmatically-controlled repositories:
* cpu types (e.g., cpu_repo.get("intel-generic") or cpu_repo.get("intel-core2duo"))
* main memory types (e.g., mem_repo.get("DDR3"))
* system organizations (e.g., single-core, multi-core with directory on 3rd-level cache, etc)
* ...

This way it should be possible for the user to re-configure these repositories by some script run by the main scripts:
  cpu_repo.add("intel-foo", parent=("intel-core2duo"), ROBSize = 128, ...)

And let the main example scripts instantiate the system and manage their execution:
  system = get_system(options)
  # other code managing how to instantiate and run the system

Where "options" can point the main scripts to another user-provided script that returns a system with a specific configuration:
  cpu_tpl = cpu_repo.get("intel-foo")
  mem_tpl = mem_repo.get("DDR3")
  system_tpl = system_repo.get("single-core")
  # configure specializes the parameters of the template
  system_cfg = system_tpl.copy().configure(cpus = cpu_tpl, mem = mem_tpl, disks=["/tmp/system.img"])
  # realize performs the actual instantiation recursively
  system = system_cfg.realize()

Although I still have no clear idea on how to elegantly handle cpu type switches. And of course, this is all very nice and everything, but I have no time resources to implement it :)
    
    
    
   
    2.