Many-to-one on a TLM

[TonyJ]

Rookie question:

Is it as obvious as it may seem to simply have just the one imp on the consumer side of say a put_port (non-blocking most likely), and multiple producers can connect to that single imp?

 

Yes, they would all be the same item types, and yes they would all be handled the same way.

 

Not the same as an analysis_port.  More like an analysis_port with the traffic flowing the opposite direction.

 

Any issues I may be overlooking or missing?

[bhunter1972]

Yes, multiple ports may be connected to a single imp, providing many-to-one functionality.

Analysis ports provide one-to-many connectivity.

[TonyJ]

Cool. Thank you sir!!

[David Black]

When considering a many to one solution, keep in mind that depending on the implementation, this could cause havoc if you care about the source of the invocation. For instance, if the imp provides a FIFO then the consumer of the information won't know where the source of the information originated unless the data itself is tagged. Also, it is possible for two accesses to be in the same delta cycle, which results in a race condition.

[TonyJ]

When considering a many to one solution, keep in mind that depending on the implementation, this could cause havoc if you care about the source of the invocation. For instance, if the imp provides a FIFO then the consumer of the information won't know where the source of the information originated unless the data itself is tagged. Also, it is possible for two accesses to be in the same delta cycle, which results in a race condition.

 

Yep....100% on everything you said.

I have actually tagged the data.  The race condition is actually the very thing I am banking on. I want the flow of these descriptors to truly be interleaved in a non-deterministic manner, as this more accurately mimics actual HW behavior.  If the users of what I'm building require tighter control, then they can manage it with say a higher level v-sequence that manages each of the attached clients generating said descriptors.

[MattW]

Is there any limitation of this applying to analysis ports, many producers connected to one write implementation.  Will the built-in blocking of the method be enough to "arbitrate" and not violate the non-blocking the nature of the port if two transactions are reported in the same time delta?  Again with this approach I want the random interleaving - first come first served.

Thanks for any comments. 

[David Black]

Analysis ports are non-blocking by definition. Subscribers are required by the standard to:

1. Not do any blocking activities (e.g. wait())
2. Not to modify any aspects of delivered reference.
3. Copy the payload if you want to extend the lifetime of the payload