TLM2.0 preempt last request

[plafratt]

With TLM2.0 nb_transport, is there a way for an initiator to tell an interconnect that it wants to preempt the last request the initiator sent?

For example, say that the interconnect can buffer only 1 request. The initiator sends a low priority request R0 to the interconnect. Some time passes, and the initiator begins another, higher priority request R1. The initiator knows that the interconnect hasn't serviced R0 yet, because the initiator hasn't received a response for R0 yet. The initiator wants to tell the interconnect, "Throw out R0 and use R1 instead."

I can achieve this by just having the initiator send R1 to the interconnect, and then having it send R0 again at a later time (after R1 is done being serviced). However, it isn't clear to me that TLM2.0 protocol allows the initiator to send R0 an arbitrary number of times in the BEGIN_REQ phase.

[plafratt]

Quote

it isn't clear to me that TLM2.0 protocol allows the initiator to send R0 an arbitrary number of times in the BEGIN_REQ phase.

I see now that the TLM2.0 LRM explicitly disallows this.

Quote

In the case of the base protocol, successive calls to nb_transport with the same phase are not permitted.

(In the version of the LRM I have, this is in the section "4.1.2.6 The phase argument".)

However, this text there does refer to the "base protocol." So, perhaps the way to allow what I am trying to do would be to define a new protocol. Any input on this is appreciated, though, in case that is the wrong way to go about this.

[Eyck]

Actually the usual bus protocols allow to send larger number of requests and the interconnect is allowed to answer them 'out of order' (e.g. AMBA AXI or CHI). But you are free to define you onw protocol and its own rules. The LRM states exactly how to do this. One example can be found at  https://github.com/Arteris-IP/tlm2-interfaces which defines the extensions and phases for the AXI/ACE and the CHI protocol.

[David Black]

@plafrattTLM2 is built to allow any protocols you like. The "base protocol" was deemed sufficient for most needs; however, TLM2 was designed specifically to allow alternatives. Furthermore, the standard provides mechanisms to keep the cost of adapters/bridges between protocols simulation efficient.

[Plug - ignore if you like] The Doulos course on TLM 2.0 <https://www.doulos.com/training/systemc-tlm-20/systemc-modeling-using-tlm-20-online/> investigates the base protocol and then builds up to a module describing custom protocols.