summaryrefslogtreecommitdiff
path: root/src/python/swig/pyobject.cc
diff options
context:
space:
mode:
authorJoel Hestness <jthestness@gmail.com>2015-08-14 00:19:44 -0500
committerJoel Hestness <jthestness@gmail.com>2015-08-14 00:19:44 -0500
commit581bae9ecbafd5e94c5405ca925a55cc6e5d7488 (patch)
treec4e9136882984e561b7c1c618361e4262b482869 /src/python/swig/pyobject.cc
parentbf06911b3f6d992dc78489d66410f4580a17db7b (diff)
downloadgem5-581bae9ecbafd5e94c5405ca925a55cc6e5d7488.tar.xz
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.
Diffstat (limited to 'src/python/swig/pyobject.cc')
-rw-r--r--src/python/swig/pyobject.cc29
1 files changed, 12 insertions, 17 deletions
diff --git a/src/python/swig/pyobject.cc b/src/python/swig/pyobject.cc
index f90e456e2..85a303b43 100644
--- a/src/python/swig/pyobject.cc
+++ b/src/python/swig/pyobject.cc
@@ -100,23 +100,18 @@ 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) && name1 != "memory" && name2 != "memory") {
- 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);
- }
-
+ // These could be MessageBuffers from the ruby memory system. If so, they
+ // need not be connected to anything currently.
+ MessageBuffer *mb1, *mb2;
+ mb1 = dynamic_cast<MessageBuffer*>(o1);
+ mb2 = dynamic_cast<MessageBuffer*>(o2);
+
+ if (mb1 || mb2) {
+ // No need to connect anything here currently. MessageBuffer
+ // connections in Python only serve to print the connections in
+ // the config output.
+ // TODO: Add real ports to MessageBuffers and use MemObject connect
+ // code below to bind MessageBuffer senders and receivers
return 1;
}