summaryrefslogtreecommitdiff
path: root/src/python/swig
diff options
context:
space:
mode:
authorNilay Vaish <nilay@cs.wisc.edu>2014-09-01 16:55:47 -0500
committerNilay Vaish <nilay@cs.wisc.edu>2014-09-01 16:55:47 -0500
commit7a0d5aafe4b845a2d1cff6210d7c6ee66e8aba61 (patch)
tree6ef6157a33d226688f2909998b71936976ee755b /src/python/swig
parent00286fc5cbb7b8635d56eb335fed11d1499e2552 (diff)
downloadgem5-7a0d5aafe4b845a2d1cff6210d7c6ee66e8aba61.tar.xz
ruby: message buffers: significant changes
This patch is the final patch in a series of patches. The aim of the series is to make ruby more configurable than it was. More specifically, the connections between controllers are not at all possible (unless one is ready to make significant changes to the coherence protocol). Moreover the buffers themselves are magically connected to the network inside the slicc code. These connections are not part of the configuration file. This patch makes changes so that these connections will now be made in the python configuration files associated with the protocols. This requires each state machine to expose the message buffers it uses for input and output. So, the patch makes these buffers configurable members of the machines. The patch drops the slicc code that usd to connect these buffers to the network. Now these buffers are exposed to the python configuration system as Master and Slave ports. In the configuration files, any master port can be connected any slave port. The file pyobject.cc has been modified to take care of allocating the actual message buffer. This is inline with how other port connections work.
Diffstat (limited to 'src/python/swig')
-rw-r--r--src/python/swig/pyobject.cc22
1 files changed, 22 insertions, 0 deletions
diff --git a/src/python/swig/pyobject.cc b/src/python/swig/pyobject.cc
index fe849ec88..51bd1f62f 100644
--- a/src/python/swig/pyobject.cc
+++ b/src/python/swig/pyobject.cc
@@ -39,6 +39,7 @@
#include "dev/etherdevice.hh"
#include "dev/etherobject.hh"
#endif
+#include "mem/ruby/slicc_interface/AbstractController.hh"
#include "mem/mem_object.hh"
#include "python/swig/pyobject.hh"
#include "sim/full_system.hh"
@@ -98,6 +99,27 @@ connectPorts(SimObject *o1, const std::string &name1, int i1,
}
}
#endif
+
+ // These could be objects from the ruby memory system. If yes, then at
+ // least one of them should be an abstract controller. Do a type check.
+ AbstractController *ac1, *ac2;
+ ac1 = dynamic_cast<AbstractController*>(o1);
+ ac2 = dynamic_cast<AbstractController*>(o2);
+
+ if (ac1 || ac2) {
+ MessageBuffer *b = new MessageBuffer();
+
+ // set the message buffer associated with the provided names
+ if (ac1) {
+ ac1->setNetQueue(name1, b);
+ }
+ if (ac2) {
+ ac2->setNetQueue(name2, b);
+ }
+
+ return 1;
+ }
+
MemObject *mo1, *mo2;
mo1 = dynamic_cast<MemObject*>(o1);
mo2 = dynamic_cast<MemObject*>(o2);