Handling of Requests with Early Responses when Initiator Can Change Transaction

[plafratt]

In systems where a target can send an early response, such as a posted write, and the initiator can change the transaction after it receives the response, how do most developers handle the transaction in the target while avoiding seeing the initiator's changes to that transaction? An obvious solution is for the target to do a deep copy of the transaction, but in a complex system with many modules, having each module potentially create its own copy of each  transaction can make debug and performance analysis difficult. Another option is for the target to save the relevant information from the transaction in an extension when the target receives that transaction, but this has the problem that the developers of the target must always remember to use the accessors in the extension, rather than the standard ones for the transaction.

[Eyck]

Since you are talking about timing I would stick to a more AT like modeling style using the non-blocking transport functions. In this case you should use a memory manager (see section 14.5 of the IEEE standard). For this you need to implement the tlm::tlm_mm_interface (there a few implementations out there, you may google them). The mechanism works similar to a C++ shared pointer. The initiator always pulls a new transaction from the memeory manager and sends via its socket. Each component dealing with the transaction calls acquire() on the payload and release() once it is finished with it. Upon the last release() call the transaction is automatically returned to the memory manager and can be reused.

HTH

[plafratt]

Thank you for the thoughts.

I am using acquire() and release() to ensure that the memory is safe while I am using the transaction in the target. The specific problem I am facing is that the initiator might call, for example, set_address() on the transaction after it receives the response, while the target is still using it. The target needs access to the original address.

[Eyck]

Why would you want to change the address after sending it? Actually only interconnect components are allowed to change the address of an transaction (this is what the standard says). I would alwys keep in mind how this is handled in haerdware....

One option to address this is to add an extension to your transaction holding the original adress and other information you need. But this comes at the cost of interoperability (if this is a criteria for you).

BR