----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2845/#review6811 -----------------------------------------------------------
Joel, your intention with this patch is to completely replace patches http://reviews.gem5.org/r/2801/ and http://reviews.gem5.org/r/2814/, correct? Hopefully we can resolve the last couple of issues on this patch and you can check it in soon. I'd like to add the finite buffer configs on top of it, as well as simple way to fallback on infinite buffers, similar to the kill switch added by 2801. Thanks - Brad Beckmann On June 20, 2015, 4:14 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2845/ > ----------------------------------------------------------- > > (Updated June 20, 2015, 4:14 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10859:d0dddb8fc9de > --------------------------- > 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) Distinguishes buffer-specific parameters from buffer-to-network parameters. > Specifically, buffer size, randomization, ordering, recycle latency, and ports > are all specific to a MessageBuffer, while the virtual network ID and type are > intrinsics of how the buffer is connected to network ports. The former are > specified in the Python object, while the latter are specified in the > controller *.sm files. Unlike buffer-specific parameters, which may need to > change depending on the simulated system structure, buffer-to-network > parameters can be specified statically for most or all different simulated > systems. > > > Diffs > ----- > > configs/ruby/Ruby.py d02b45a554b5 > src/mem/protocol/RubySlicc_Defines.sm d02b45a554b5 > src/mem/ruby/SConscript d02b45a554b5 > src/mem/ruby/network/MessageBuffer.hh d02b45a554b5 > src/mem/ruby/network/MessageBuffer.cc d02b45a554b5 > src/mem/ruby/network/MessageBuffer.py PRE-CREATION > src/mem/ruby/network/SConscript d02b45a554b5 > src/mem/ruby/network/simple/SimpleNetwork.hh d02b45a554b5 > src/mem/ruby/network/simple/SimpleNetwork.cc d02b45a554b5 > src/mem/ruby/network/simple/SimpleNetwork.py d02b45a554b5 > src/mem/ruby/network/simple/Switch.hh d02b45a554b5 > src/mem/ruby/network/simple/Switch.cc d02b45a554b5 > src/mem/ruby/slicc_interface/AbstractController.hh d02b45a554b5 > src/mem/ruby/slicc_interface/AbstractController.cc d02b45a554b5 > src/mem/slicc/ast/ObjDeclAST.py d02b45a554b5 > src/mem/slicc/symbols/StateMachine.py d02b45a554b5 > src/python/swig/pyobject.cc d02b45a554b5 > > 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
