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

Hi Yossi,

  I just went and read them in isolation out of context and yes I agree with you. However I don't find it all that important: It is adequately clear in the documentation that you aren't required to do things that way; that they aren't rock-hard-rules. The wording could be friendlier to the interpretation I am trying to encourage.

Cheers,
James

Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

________________________________
From: Veller, Yossi [mailto:Yossi_Veller@mentor.com]
Sent: Thursday, January 06, 2011 4:56 PM
To: Aldis, James; john.aynsley@doulos.com; robert.guenzel@greensocs.com
Cc: P1666 Technical WG; tlmwg@lists.systemc.org
Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules

Hi James,

I can agree with you in principle.
So do I understand correctly the meaning of your mail is that the rules 16.2.6 b) and c) are superfluous because they over-document the meaning of the timing points in the BP (the read rule tends to AXI and not AHB)?

Regards
Yossi

From: Aldis, James [mailto:j-aldis2@ti.com]
Sent: Thursday, January 06, 2011 4:43 PM
To: Veller, Yossi; john.aynsley@doulos.com; robert.guenzel@greensocs.com
Cc: P1666 Technical WG; tlmwg@lists.systemc.org
Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules

Yossi,

  This is not about in-order or out-of-order responses. It is about interrupibility of requests and responses. A
bus that has separate physical wires for read/write address or read/write response is usually interruptible in
this way. Vast numbers of bus protocol standards share the same wires for read/write address and
read/write response. A huge number even share the same wires for read/write data! Where wires are
shared interruption/interleaving is rarely possible.

  Obviously you can use the BP to approximate AXI. Obviously it won't be as good as using a slightly
modified protocol allowing overlapping RD/WR requests and responses, and possibly adding write data
bus phases. The pertinent questions are "how close can you get using the BP and is it really so bad
as to justify losing the BP-compatibility?" The answers will depend on what your component
model is for.

  If you were to decide (for example) to always send immediate END_REQ and END_RESP and let the
components take joint responsibility for calculating the durations of bus occupancy, then your example would
work just fine. Your initiator and target ought then to be BP-compatible. In combination they would
correctly represent your system. Either one of them in combination with someone else's initiator or
target would be functionally correct but possibly a bit wierd in terms of timing accuracy. It's my opinion
that this is valuable nonetheless - basic functional compatibility means system models available sooner
means TLM modelling more successful. The oddities can be cleaned up later if necessary - in many
many cases it won't be necessary.

  And that's why I think it inappropriate for OSCI to over-document the meaning of the timing points in
the BP (what you call transfer time) - different meanings might be appropriate for AXI and AHB, for example.
On the other hand it seems wholly appropriate for people outside OSCI to agree on how best to model
specific bus interfaces.

James

Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

________________________________
From: tlmwg@lists.systemc.org [mailto:tlmwg@lists.systemc.org] On Behalf Of Veller, Yossi
Sent: Thursday, January 06, 2011 2:47 PM
To: john.aynsley@doulos.com; robert.guenzel@greensocs.com
Cc: P1666 Technical WG; tlmwg@lists.systemc.org
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.