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

I agree with Robert. Moreover, 16.2.6 b) and c) were added (following a
discussion with Marcelo, if I remember correctly) to highlight the
symmetry between the request and response exclusion rules and to help
explain how an application can choose to use these rules to model channel
occupancy.

John A

From:
Robert Guenzel <robert.guenzel@greensocs.com>
To:
"Veller, Yossi" <Yossi_Veller@mentor.com>
Cc:
"Aldis, James" <j-aldis2@ti.com>, john.aynsley@doulos.com, P1666 Technical
WG <systemc-p1666-technical@eda.org>, tlmwg@lists.systemc.org
Date:
06/01/2011 16:09
Subject:
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.