> On May 27, 2015, 12:22 a.m., Brad Beckmann wrote:
> > I just have two questions so far on this patch.
> > 
> > 1. What does Nilay mean that the "we are dropping the functionality of 
> > connecting buffers in python"?  It wasn't too long ago when we added that 
> > functionality rather than doing it in the controller constructors.  Why is 
> > that functionality going away and how was that decision determined?
> > 2. Joel was it your intention to post this patch without moving the 
> > MessageBuffers created within the network (not the endpoints) to python?  
> > Was that to get early feedback before doing the possibly harder job of 
> > dealing with those other MessageBuffers?  Were you hoping that Mark 
> > Wilkening to pick this patch up and add that support?
> > 
> > 
> > Thanks

1. I just made a quick decision to remove the buffer connection code in 
pyobject.cc. It wasn't clear to me that it was actually doing anything, because 
it just called into C++ code, which is generated to connect the buffers. I see 
Nilay's point that the connections are printed in the config.ini. It would be 
easy to add this back (though I still feel it is convoluted to connect a buffer 
to a port). I'll be looking for ways to address this.
2. Yes, I created this patch quickly in an effort to get feedback and to 
hopefully start us toward handling buffers in Python code. I have not yet 
looked at what it would take to move the buffers from the Switch and 
SimpleNetwork into Python code. I still prefer that we not introduce buffer 
sizing inside cache controllers, and I'm hoping we can align on a 
Python-configurable way to do it.

I'm willing to invest time in Python-configurability of MessageBuffers, because 
it will very likely save me time later. Please let me know if you like the 
direction of this patch (exposing MessageBuffers in Python), or if you think we 
should do that another way.


- Joel


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2845/#review6403
-----------------------------------------------------------


On May 25, 2015, 11:51 p.m., Joel Hestness wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2845/
> -----------------------------------------------------------
> 
> (Updated May 25, 2015, 11:51 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> Changeset 10850:0fc919c768b2
> ---------------------------
> ruby: Expose MessageBuffers as SimObjects
> 
> Expose MessageBuffers from SLICC controllers as SimObjects that can be
> manipulated in Python. This patch has numerous benefits:
> 1) First and foremost, it exposes MessageBuffers as SimObjects that can be
> manipulated in Python code. This allows parameters to be set and checked in
> Python code to avoid obfuscating parameters within protocol files. Further, 
> now
> as SimObjects, MessageBuffer parameters are printed to config output files as 
> a
> way to track parameters across simulations (e.g. buffer sizes)
> 2) Cleans up special-case code for responseFromMemory buffers, and aligns 
> their
> instantiation and use with mandatoryQueue buffers. These two special buffers
> are the only MessageBuffers that are exposed to components outside of SLICC
> controllers, and they're both slave ends of these buffers. They should be
> exposed outside of SLICC in the same way, and this patch does it.
> 3) Removes the obfuscated port-like connection of MessageBuffers. Ports are
> now connected in the init function of the generated controllers.
> 
> 
> Diffs
> -----
> 
>   src/mem/protocol/RubySlicc_Defines.sm e61f847e74fd 
>   src/mem/ruby/network/MessageBuffer.hh e61f847e74fd 
>   src/mem/ruby/network/MessageBuffer.cc e61f847e74fd 
>   src/mem/ruby/network/SConscript e61f847e74fd 
>   src/mem/ruby/network/simple/SimpleNetwork.cc e61f847e74fd 
>   src/mem/ruby/network/simple/Switch.cc e61f847e74fd 
>   src/mem/ruby/slicc_interface/AbstractController.hh e61f847e74fd 
>   src/mem/ruby/slicc_interface/AbstractController.cc e61f847e74fd 
>   src/mem/slicc/symbols/StateMachine.py e61f847e74fd 
>   src/python/swig/pyobject.cc e61f847e74fd 
> 
> Diff: http://reviews.gem5.org/r/2845/diff/
> 
> 
> Testing
> -------
> 
> Regression tests with all Ruby protocols. Protocol file changes are in
> separate patch (http://reviews.gem5.org/r/2844/) to keep this one slim.
> 
> 
> Thanks,
> 
> Joel Hestness
> 
>

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

Reply via email to