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.