Jump to content

TLM 2.0 Temporal Decoupling / b_transport delay parameter

Recommended Posts

Hi All,

This is regarding to TLM 2.0 topic is Temporal Decoupling in LT modeling and b_transport delay parameter.

My first query is what is the need of passing delay in b-transport call. I read from the below link 


it says


"In your third example, the idea of the delay parameter is that this represents the offset from systemc time (sc_time_stamp()). In my description above, I assumed the target did *not* call wait. However if the target *does* call wait, then the offset must be reset to 0 ns, because sc_time_stamp() has increased."

Nitin S -> I am considering there is no wait and it is said that, if there is not wait then the execution will be completed without consuming time in slave. So, then why we are passing the delay? 

So, what is the use of  


"The delay returned by the target does represent the time at which the response should be considered to have arrived (relative to sc_time_stamp()), which is the time at which the transaction ends."


"You can think of  b_transport as representing a protocol with only two timing points, the time at which the request is sent, and the time at which the response is received.

As we know that in LT model we give least priority to time factor so why we need " b_transport as representing a protocol with only two timing points, the time at which the request is sent, and the time at which the response is received"??? 

Note all bold letter are written in quote are from "http://forums.accellera.org/topic/110-b-transport-interface/#entry426"


Thanks and Regards,

Nitin S

Link to comment
Share on other sites

In LT with Temporal Delay, the initiators maintain a local variable (sometimes with the aid of the Quantum Keeper) that represents time. Although time is not as important, we don't want to throw it completely away. So each initiator keeps a variable that represents how far ahead of the simulator's notion of time it has progressed. You can represent execution of instructions by simply adding a time value to that variable. Targets want to know the current simulated (not simulator) time so they can respond appropriately. For example, a timer definitely needs a notion of time in order to timeout. So initiators pass their local notion of the "current time" to the target. If a target wants to represent the notion of a time change, it can add to that delay, which will be reflected in the initiator since the b_transport call passes it by reference.

LT models don't completely avoid sc_core::wait(), but they do try to minimize it because context switches affect performance. Adding to a local variable doesn't have as much of a hit.

Link to comment
Share on other sites

  • 9 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...