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

Yossi,

I cite John
> From the outset, I have been concerned about the way you seem to be
> interpreting 16.2.6 b) and c). Note that these are not "rules" in the
> sense that they do not impose any specific obligations.
Maybe that answers your question?

But still I would not call them superfluous. They are hints or
recommendations.

best regards
Robert

Veller, Yossi wrote:
>
> 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.