Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won

  1. Explicit parent object

    I agree. We won't stop using dynamic port creation, because it makes life so much easier. So either we'll have to live with a messed up hierarchy, or get a good standard compliant way to achieve it. Or as now, use a non-compliant method. Also, we've just started modeling power gating in TLM, which relies on traversing the SystemC object hierarchy and e.g. making sockets aware that they are off and resetting stuff after power on. With a messed up hierarchy, this might break down.
  2. Explicit parent object

    So the bottom line is that it can be done today, but in a rather convoluted and non-obvious way. Or in a way that isn't standard compliant.
  3. Explicit parent object

    Interesting. Seems like a nice solution, but will unfortunately break a lot of code as the API would change. Thinking a bit more about it. Maybe what would be useful is something similar to SystemVerilogs bind statement? In C++, I don't think this could be exactly the same, but it could at least affect the name-scoping.
  4. Explicit parent object

    In the example, only the interconnect allocates sockets "on demand". I agree that it would be less useful for the other modules. Maybe the example should have said: "cpu.init.bind(interconnect.tgt("cpu"));" etc, instead for clarity. The interconnect module will add handlers for b_transport() etc for each added socket, then use the memory mapping information given to route transactions and DMI requests and invalidations. So nothing strange there. And yes, multi socket can be used, but does not solve the naming problem that was my original concern. I.e. that the sockets become visible in the hierarchy with the names given when connecting ("ic.mem", "ic.cpu" and "ic.uart" in the example). Disregarding the naming, our existing solution works just fine. And I have not looked at the sc_vector stuff yet.
  5. Explicit parent object

    The sockets are simply bound to other sockets. E.g: class my_module: public sc_module { ... xbar interconnect{"ic"}; // This module allocates socket "on request" cpu cpu{"cpu"}; mem mem{"mem"}; uart uart{"uart"}; ... my_module(...) ... { cpu.init(interconnect.tgt("cpu")); mem.tgt(interconnect.init("mem")); uart.tgt(interconnect.init("uart")); interconnect.map("mem", 0, 0x1000); interconnect.map("uart", 0x1000, 0x100); ... It is mainly a convenience thing, to not have to specify the interconnect ports twice. It is also makes reuse easier as the names and number of ports of an interconnect can depend on e.g. elaboration time parameters. We also use this mechanism when connecting SystemC to Python. In that case the Python interpreter is a module where ports are allocated on demand from SystemC. These sockets are then available to Python code.
  6. Explicit parent object

    OK. Thanks! The first version seems to work nicely for my case. I do not see any error messages: tlm::tlm_initiator_socket<> *port_repos<T>::add_init(const std::string &name) { ... sc_core::sc_get_curr_simcontext()->hierarchy_push(&this->module); init_sock_t *sock = new init_sock_t(name.c_str()); sc_core::sc_get_curr_simcontext()->hiearchy_pop(); ... return sock; } The second version is probably less portable as it includes a file not intended to be included, according to the comments in the file. Thanks, -stefan
  7. Explicit parent object

    In our code we sometimes create sockets on demand. I.e. when some other modules ask for a socket during elaboration of the design instead of in the constructor of the module to which the socket belongs. This works great in general, but the hierarchical name of the created sockets end up in the scope of the module asking for the socket rather than in the scope of the module that has the socket. So when creating the sockets I would need to be able to explicitly set the parent object of the socket, but I haven't yet found a way to do this. Is there a way, or is this something to add to upcoming revisions of the standard and POC simulator?