Advantage of TLM fifo over a mailbox

Hi All,

Can somebody tell me any advantage of using TLM fifo over a mailbox for connecting components?
Suleesh

Suleesh,

A TLM fifo is a mailbox implemented using standard TLM ports and exports as an API to the mailbox. The TLM API gives you a separation of concerns which in turn promotes re-usability and maintainability.

Let’s say you have two components: A and B. Component A has a thread doing puts and component B has a thread doing gets. They are both connected through a common mailbox which means they both must declare handles to a matching mailbox type. This creates an unwanted dependency. At some point, I might want some other component other than a mailbox to connect to, like some kind of arbitrator. So I would have to modify the handles types in the components.

TLM gets rid of that dependency. Component A can have a put_port and just requires that what it is connected to implements a put method. Component B can have a get_port and just requires that what it is connected to implements a get method.

Dave

In reply to dave_59: what type of dependency it ll create

In reply to sivareddy:
As I said above, using a mailbox forces a connection between components to use a mailbox protocol where there is one thread calling a mailbox.put(t), and another thread calling a mailbox.get(t).

When you use a TLM port, you just call put(t) and have no knowledge of how the put is implemented. You just know that a put() blocks until the transfer of t completes. In the case of a TLM fifo, the TLM put()happens to be implemented as a mailbox.put(), but the calling process does not know that. It is possible that the implementation of put does everything and there is no need for another process to do a get().

Hi @dave_59 , can we implement typeless mailbox and add synchronisation between them using try_get() method in receiver side ? I guess if mailbox is declared type less we can pass any type of arguments ?
From LRM - try_get() will return negative numbers is type is mismatched. so later we can add out of order kind of logic receiving logic to detect type of the packet.

I would avoid using typeless mailboxes. A typed mailbox will throw a compiler error if not constructed correctly. On the other hand, a typeless mailbox might let you to wait until runtime to issue an error, and even then, you might not ever see an error, potentially leading to a deadlock or a livelock.