Non blocking communication in TLM2.0
Posted by haribali on July 2nd, 2012
In this blog I want to introduce how non-blocking communication works in TLM-2.0. This is same in UVM, VMM and SystemC. Only the names of the functions and arguments may differ.
As name suggests, non-blocking communication returns immediately. Due to this behavior target may or may not process the request immediately when the nb_transport_fw function is called. For this very reason we have backward path using which target can intimate initiator whenever the request is processed using nb_transport_bw method. We can look at this as 2 function calls one from initiator to target for sending the request and second is from target to initiator for sending the response once the request is processed.
If this is as simple as shown above then why do we need an additional argument in form of phase and a return type. Let’s see what these additional arguments are conveying. I have used the term “partner” (as in link partner) in the blog to identify either target or initiator.
Phase argument in the nb_transport function calls is used to communicate the phase of this transaction. Phase can be one of the following
BEGIN_REQ: This is sent by initiator along with the transaction to tell the target that this is a new request.
END_REQ: This is sent by target to tell the initiator that request has accepted but not yet processed.
BEGIN_RESP: This is sent by target to tell initiator that request is processed and this is the response for the corresponding request.
END_RESP: This is sent by the initiator to tell target that response has been accepted. With this the transaction is complete.
Return type for the nb_transport function calls is used to tell the partner (initiator/target, whoever initiated the call) whether the transaction is processed at this stage or not. Return type can be one of the following
TLM_ACCEPTED: This is used to tell the partner (Initiator/target, whoever initiated the call) that transaction is accepted but processing has not yet started. Whenever this is returned we can simple ignore the arguments as they are not changed.
- Target returns TLM_ACCEPTED when it has accepted the request sent by the initiator but not processed yet. Initiator need not process the function arguments as they are not changed by the target.
TLM_UPDATED: This is returned to tell the partner (initiator/target, whoever initiated the call) that the transaction is accepted and the function arguments are modified.
- Target returns TLM_UPDATED when it has accepted the request sent by the initiator and modified the function arguments. Initiator need to take action depending on the phase argument.
TLM_COMPLETED: This is returned to tell the partner (initiator/target, whoever initiated the call) that the transaction is completed and the function arguments are modified.
- Target returns TLM_COMPLETED when it has accepted the request sent by the initiator and completed processing it. Initiator need to take action depending on the phase argument.
In summary, non-blocking interface has a protocol associated with it which is used to make sure each transaction is properly processed and communicated the response back. If you see the blocking interface, this is not required as initiator waits for target to complete the transaction. In non-blocking there would be no way for initiator to know if the target processed the transaction or not without this protocol.
Non-blocking coding style is generally used in coding accurate models in virtual prototypes. If you are planning to use TLM models from virtual platform to speed up your simulations or for any other reasons then you will end up connecting the non-blocking TLM models to your verification environment where non-blocking interface will be useful. I welcome you to share other use cases of non-blocking interface.