> On 2011-07-11 11:38:24, Brad Beckmann wrote:
> > Is it necessary for the fault model to be configured using a text file?  
> > Can you do this in python instead?  For instance, if you used scripts to 
> > generate the files, it would be best if you implemented those scripts in 
> > python and used the standard sim_object methodology.  Also is the one text 
> > file just a "temp" file?  If so, should it be checked it?
> 
> Konstantinos Aisopos wrote:
>     These 2 text files are a small database generated by my infrastructure 
> (PrimeTime+SPICE), and is used to calculate the fault vector based on the 
> routers' configuration and the current environmental conditions. 
> Specifically, DB.conf.txt stores the fault vectors for a number of baseline 
> configurations, while DB.temp.txt stores weights applied to vectors (these 
> weights reflect how much higher the fault probabilities will be) while 
> temperatures increase.  
>     
>     Thus, these two files are a part of the fault model's "code" and not a 
> user input. The fault model's user is not supposed to ever change these 
> files, that's why I do not consider a good idea to put them together with 
> gem5 inputs. In practice, I (or whoever maintains this tool in the future) 
> should only edit these files. For instance, if in the future I want to 
> incorporate additional technologies (eg 32nm) or additional router 
> configurations in the fault model, I can do so by using my infrastructure to 
> generate 2 updated DB files and provide you another gem5 patch. 
>     
>     The actual input to my fault model is the network configuration (routers' 
> input/output ports, buffers, VCs, etc) which is read  directly from Garnet. 
> Currently, the only actual input that the user can control  is the 
> enable/disable flag (i.e., enable_fault_model in 
> src/mem/ruby/network/garnet/BaseGarnetNetwork.py)
>     
>     Let me know if you think my argument makes sense, or you still think the 
> database files should be a python input.
> 
> Brad Beckmann wrote:
>     Thanks for the explanation.  If the text files are generated by 
> PrimeTime+SPICE, then I agree, it doesn't make a lot of sense to integrate 
> the text file data directly into a python script.  However, I would suggest 
> moving the text file parsing out of C++ and into Python.  As I'm sure you 
> know, Python is much cleaner than C++ when comes to parsing text.
>     
>     Also I would suggest renaming the text files to more meaningful names.  
> For instance: baseline.fault-vectors.txt and baseline.temp-weights.txt.
>     
>     Finally, instead of including a README file in the directory, you should 
> put that information on the wiki.
> 
> Konstantinos Aisopos wrote:
>     OK.
>     Regarding "moving the text file parsing out of C++ and into Python": I am 
> not very familiar with Python, but if you consider this critical I could read 
> on Python a little bit. However, assuming the file is parsed in python, how 
> do I then make C++ read the parsed objects? Any pointers to gem5 code where 
> something similar is done?
> 
> Brad Beckmann wrote:
>     There are many examples where arrays created in python are then 
> translated into C++.  One such example is the Process envirnoment array (see 
> sim/process.*, sim/Process.py).
>     
>     I know it may seem like I'm being a "stickler" here, but please 
> understand that gem5's Python-based configuration process is a key component 
> of the infrastructure.  We want all configuration to go through that process 
> and not have a situation where certain components bypass the process and do 
> configuration a different way.

Tushar helped me out to create a python class in a new file (FaultModel.py) and 
showed me how to interface it with C++. Btw, I think it would be nice if you 
would  document this procedure into your wiki (it's hard for someone who hasn't 
used gem5 before to figure out what's going on)

But then, I looked into the files you pointed out and could not find a case 
where an array (with data; not an empty one) is read from a file into python. I 
decided that it might just be simpler to add my fault model's database (a huge 
array of floats) directly into FaultModel.py (instead of keeping it in a txt 
file), but the functionality to declare a vector with data does not seem to be 
there in gem5, unless I used the wrong syntax (did I?):

----------FaultModel.py---------------
from m5.params import *
from m5.SimObject import SimObject

class FaultModel(SimObject):
    type = 'FaultModel'
    cxx_class = 'FaultModel'
    test = VectorParam.Int([1, 2, 3], "");       <---- this line (a test vector 
with 3 elements) results in a seg fault
----------/FaultModel.py---------------

this compiles fine but, at runtime, I get a seg fault because of "test":

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/main.py", line 
356, in main
    exec filecode in scope
  File "configs/example/ruby_network_test.py", line 131, in <module>
    m5.instantiate()
  File "/data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/simulate.py", 
line 78, in instantiate
    for obj in root.descendants(): obj.createCCObject()
  File "/data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/SimObject.py", 
line 881, in createCCObject
    self.getCCParams()
  File "/data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/SimObject.py", 
line 836, in getCCParams
    value = value.getValue()
  File "/data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/SimObject.py", 
line 885, in getValue
    return self.getCCObject()
  File "/data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/SimObject.py", 
line 866, in getCCObject
    params = self.getCCParams()
  File "/data/lsp/kaisopos/GEM5_Fault_Model/gem5/src/python/m5/SimObject.py", 
line 840, in getCCParams
    assert not len(vec)
TypeError: object of type 'PySwigObject' has no len()
Segmentation fault

any suggestions?


- Konstantinos


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/776/#review1408
-----------------------------------------------------------


On 2011-07-08 17:46:10, Konstantinos Aisopos wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/776/
> -----------------------------------------------------------
> 
> (Updated 2011-07-08 17:46:10)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan 
> Binkert, Brad Beckmann, and Tushar Krishna.
> 
> 
> Summary
> -------
> 
> GARNET: adding a fault model for resilient on-chip network research.
> 
> This patch adds a fault model, which provides the probability for a number of
> architectural faults in the interconnection network (e.g., data corruption,
> misrouting). These probabilities can be used to realistically inject faults
> in GARNET and faithfully evaluate the effectiveness of novel resilient NoC
> architectures.
> 
> 
> Diffs
> -----
> 
>   src/mem/ruby/network/fault_model/DB.conf.txt PRE-CREATION 
>   src/mem/ruby/network/fault_model/DB.temp.txt PRE-CREATION 
>   src/mem/ruby/network/fault_model/FaultModel.hh PRE-CREATION 
>   src/mem/ruby/network/fault_model/FaultModel.cc PRE-CREATION 
>   src/mem/ruby/network/fault_model/README PRE-CREATION 
>   src/mem/ruby/network/fault_model/SConscript PRE-CREATION 
>   src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 7907b19fbe80 
>   src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 7907b19fbe80 
>   src/mem/ruby/network/garnet/BaseGarnetNetwork.py 7907b19fbe80 
>   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 7907b19fbe80 
>   src/mem/ruby/network/garnet/fixed-pipeline/Router_d.hh 7907b19fbe80 
>   src/mem/ruby/network/garnet/fixed-pipeline/Router_d.cc 7907b19fbe80 
> 
> Diff: http://reviews.m5sim.org/r/776/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Konstantinos
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to