Hi Gabriel,
I agree it's not intuitive and it's a bit awkward.
Is there a reason for adopting that design? My guess is that it allows to
> build the system top to bottom in the python scripts.
>
Haha! No, there's not an underlying reason for this. In fact, I would guess
that there is a much bett
Hi Jason,
Thanks for your reply, it should be an adequate solution, even if it looks kind
of awkward to me right now ;)
While I wanted the downstream controller (B) to have a reference to the
upstream (proxied) controller (A), I must actually do the opposite and have (A)
store a reference to (B
Hi Gabriel,
First, Ruby is a bit of a mess as far as circular dependencies go. Some of
this is historic, and some of it is inherent to the design. I'm not too
surprised you're running into this issue.
The SimObject initialization is documented here:
http://doxygen.gem5.org/release/current/classSi
I am currently hacking my way through it using the NodeID (e.g, (A).version on
python side) as a parameter of controller (B) so that I can basically write in
(B)'s state machine :
MachineID proxiedController :=
createMachineID(MachineType:, proxiedNodeID);
It seems to work for now but I wou
