TLM2 port hierarchical connections with different direction

[SumitK]

Hi Folks

Is it allowed to connect an initiator port to a target port up in the hierarchy ?

Is it allowed to connect an target port to a initiator port up in the hierarchy ?

I assume no but what I observe that OSCI systemc implementation allows this.

I tried to reproduce this problem with a small example(attached) where I have a component model with following ports

tlm_utils::multi_passthrough_initiator_socket<model,32, tlm::tlm_base_protocol_types,0,SC_ZERO_OR_MORE_BOUND>  master;
tlm_utils::multi_passthrough_target_socket<model,32, tlm::tlm_base_protocol_types,0,SC_ZERO_OR_MORE_BOUND>  slave;

Then I create a subsystem with an instance of above component model and a following port

tlm_utils::multi_passthrough_initiator_socket<model,32, tlm::tlm_base_protocol_types,0,SC_ZERO_OR_MORE_BOUND>  master;

Then if I connect

model_inst->master.bind(master); // this is fine
master.bind(model_inst->slave); // this should not allowed, I think

I am attaching the complete code.

Can you help me to understand whether it is allowed ? 

Thanks

Sumit

 

test.cpp

[Eyck]

Hi Sumit,

of course it is allowed to bind an initator to a target socket, otherwise you would not be able connect an initiator to a target. But a can only once do this so usually you do it at the top level of connectivity. The picture below illustartes this, between module1 and module2 you have a binding of intor to target.

+------------------------+               +----------------------+
| +---------------+      |               |                      |
| |               |      |               |      +-------------+ |
| |               |      |               |      |             | |
| |   intor       |      |               |      |    target   | |
| |   module    +-+-+  +-+-+ intor to  +-+-+  +-+-+  module   | |
| |             | I +--+ I +-----------+ T +--+ T |           | |
| |             +-+-+  +-+-+  target   +-+-+  +-+-+           | |
| |               |      |               |      |             | |
| |               |      |               |      |             | |
| +---------------+      |               |      +-------------+ |
|                module1 |               |module2               |
+------------------------+               +----------------------+

HTH

-Eyck

[SumitK]

Hi Eyck

I agree with you that it is allowed to direct connect an initiator(target) socket to target(initiator) socket but my question is related to hierarchical connections.

As far as I know, it is allowed to hierarchically connect the following

- initiator socket of child object to  initiator socket of parent

- target socket of child object to an target socket of parent

but what about following

- connecting initiator socket of child object to target socket of parent

- connecting target socket of child object to initiator socket of parent

In my understanding these should not be allowed but if I do that there is no compilation/elaboration errors

Thanks

Sumit

[maehne]

I suggest that you read in IEEE Std 1666-2011 the introduction to the socket concept in clause 10.4 and then the rules for:

• multi-sockets in clause 16.1.4.4
• tlm_base_initiator_socket and tlm_base_target_socket in clause 13.2.4 of. 
• ports in clause 5.12.4
• exports in clause 5.13.4

Initiator sockets are derived from a port for interface method calls on the forward path and has an export for interface method calls on the backward path. For target sockets it is vice versa. Therefore, when you bind() sockets, the bind actually happens on the port and export. That's why the constraints on usage for ports and exports apply. For sc_port the following paragraph is relevant:

Quote

Suppose a particular port is instantiated within module C, and module C is itself instantiated within module P. It is permissible for the port to be bound at some point in the code remote from the point at which module C is instantiated, it is permissible for the port to be bound to a channel (or another port) that is itself instantiated in a module other than the module P, and it is permissible for the port to be bound to an export that is instantiated somewhere other than in a child module of module P. However, all such cases would result in a breakdown of the normal discipline of the module hierarchy and are strongly discouraged in typical usage.

For sc_export it is:

Quote

It is strongly recommended that an export within a given module be bound within that same module. Furthermore, it is strongly recommended that the export be bound to a channel that is itself instantiated within the current module or implemented by the current module or bound to an export that is instantiated within a child module. Any other usage would result in a breakdown of the normal discipline of the module hierarchy and is strongly discouraged (see 5.12.4).

Therefore, your example may not generate an error during compilation and elaboration, but may still disrespect the normal discipline of the module hierarchy.

[SumitK]

Hi Guys

In this case the SystemC implementation shouldn't allow hierarchical connections between ports having different directions

What you think ?

Thanks

Sumit

 

[maehne]

As my quotes from the LRM show: It is not forbidden, but strongly discouraged. Therefore, a SystemC implementation may issue a warning if the module hierarchical is not respected, but it is not required to do so. The proof-of-concept implementation of SystemC currently doesn't do this.