TLM 2.0 Temporal Decoupling / b_transport delay parameter

[Nitin_S]

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 

http://forums.accellera.org/topic/110-b-transport-interface/#entry426

it says

Quote

"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  

Quote

"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."

Quote

"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

[David Black]

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.

[Nitin_S]

Thanks David

I got your points.