Sequencer->RubyPort->MemObject->ClockedObject is the inheritance tree, so Sequencer does not inherit from RubySystem. Are you suggesting to change the inheritance tree so that the Sequencer does inherit from RubySystem instead? 

To do that, I think the inheritance structures for these ruby classes need to modified, such that they still inherit from MemObject at some point in the tree (e.g. Sequencer depends on it for issuing retries / port interface). 

I think before the introduction of the ClockedObject class, that RubySystem inherited from MemObject, in which case having RubyPort inherit from RubySystem would work. The other ruby files such as BankedArray, RubyMemoryControl, etc. use g_system_ptr->clockPeriod() instead of just clockPeriod() for the same reason (they inherit directly from ClockedObject instead of MemObject).

I guess if that is a long-term goal, I can change the inheritance structure for the corresponding Ruby Classes.

Hi Malek,

My idea was not to change the C++ inheritance structure, but rather the Python object hierarchy. Every clocked object inherits its clock from the parent by default, so assuming the Sequencer is a child of the RubySystem, it already has the same clock (period).

Thus, if it looks something like below, the sequencer can simply do clockPeriod instead of going via the system:
system.ruby = ...
system.ruby.sequencer[0] = ...

You can check in the config.ini/json what the clock (period) of the sequencer is, and I am fairly sure this is already taken care of. This should also apply to all the other clocked objects that live inside the RubySystem (there should thus be no need to do the system_ptr-> indirection).

I hope that answers your question.