RE: [tlmwg] Revisit of the TLM2.0 phases rules

Yossi,

Sorry if this is obvious to you. but I would just add:

* The meaning of a timing annotation in TLM-2.0 is fundamentally
ambiguous. The recipient cannot know whether a timing annotation
represents a delay or a time warp. In TLM-2.0, there is no discernible
difference.

* Fundamentally, transfer times, delays, and latencies are modeled
internally within components outside the scope of the TLM-2.0
interoperability layer, so I disagree that TLM-2.0 should pin down "who is
responsible to calculate the transfer time" any further than it does at
present.

* The nb_transport phase transitions do affect flow control, but as Robert
pointed out, the flow control rules rely on execution order and not on
timing annotation. So no single component can control the timing accuracy
for a transaction (because other components can warp time). As James
pointed out, at the level of the socket, a component is free to unblock
the flow (send END_REQ/END_RESP) provided it can accept further
transactions, and doing so does not necessarily imply that the end-to-end
protocol can be pipelined. It merely concerns local flow control at one
socket.

Cheers,

John A

From:
"Veller, Yossi" <Yossi_Veller@mentor.com>
To:
<john.aynsley@doulos.com>, <robert.guenzel@greensocs.com>
Cc:
"P1666 Technical WG" <systemc-p1666-technical@eda.org>,
<tlmwg@lists.systemc.org>
Date:
06/01/2011 13:46
Subject:
RE: [tlmwg] Revisit of the TLM2.0 phases rules

Hi John and Robert,
 
There SHOULD be a rule that specifies who is responsible to calculate the
transfer time (apart from the bus latencies). Otherwise it may happen that
both the target and the initiator may consume the time or none of them.
Hence that why I interpreted 16.2.6 b) and c) as rules.
 
About the timing of the write it is more natural to interpret the
END_REQ->BEGIN_RESP time frame as the data transfer phase and leave the
BEGIN_REQ->END_REQ time frame of both read and write to the address
request channel (that exists in most busses). Hence I would prefer it
specified this way or at least not specify it at all in 16.2.6 b (that
you?ve said is really not a rule).
 
For out-of-order protocols I think that I?ve shown that the TLM2 rules
contribute to scenarios that don?t seem plausible (with all due respect to
one-of-a-thousand configuration of OCP). E.g. I would not use the BP to
approximate AXI (which seems to me a pretty common protocol) because of
the scenario that I?ve shown. Otherwise one can model pretty accurately
the throughput of AXI with the BP. This is a critical limitation in my
view. OK, I stopped using the word broken, I agree with Robert that for
in-order protocols the scenario that I?ve shown does not appear.
 
The removal of the BEGIN_RESP (rule16.2.6 f) can fix the problem. At first
I contend that an initiator should not anyways issue too many outstanding
requests that it can?t handle. Hence there is no real need to enable it to
stop responding targets through this rule.
 
The removal rule16.2.6 f will also enable the following scenario:
There are two targets T1 and T2 (T2 has higher priority). T1 sends a read
burst through B and some time afterwards T2 requests also to send a read
burst. The bus can send a BEGIN_RESP to the initiator in order to show
that the higher priority request preempts the lower priority one and the
master can first finish the higher priority transaction and delay the end
of the lower priority one accordingly. Almost the same scenario (only that
the lower priority transaction?s end can follow the end of the higher
priority transaction?s end) can model interleaving of the data of slower
higher priority bursts and faster lower priority bursts.
 
Conceptually thinking of the write data as passing in the
END_REQ->BEGIN_RESP time frame will also show the way for modeling
preemption and data interleaving on write transactions in a similar way to
the read.
 
So slightly changing the rules will bring big advantages and make BP
conformable with more actual protocols. Don?t you think so?
 
Regards
Yossi
 
BTW I did not mean any timing annotations to be used in my example. The
initiators, target and bus all schedule delayed event notifications and
call nb_transport at the right time. My apologies for the sloppiness with
which I've written the example that just caused confusion.
 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.