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

Yossi,

The current rules specify that attributes (including data) can be processed by a target between BEGIN_REQ and BEGIN_RESP (as shown in the picture at the end of section 16.2.6) so I don't think your argument holds that it is not possible to model the features you are looking for.

I do agree that there are no guarantees that a model will behave as you want, but we have not set any guarantees for the accuracy of the AT BP anyway...
Restricting the BP timing rules as you propose wouldn't change that.

Bart

|-----Original Message-----
|From: Veller, Yossi [mailto:Yossi_Veller@mentor.com]
|Sent: Tuesday, January 11, 2011 3:34 PM
|To: Aldis, James; Robert Guenzel
|Cc: Marcelo Montoreano; Bart Vanthournout; john.aynsley@doulos.com;
|P1666 Technical WG; tlmwg@lists.systemc.org
|Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules
|
|Hi James, all,
|
|My goal is the same as yours: to get the BP as useful as it can so that
|users will use it unless they really need much more accuracy. I
|understand like you that it will never be able to fully model any
|protocol that you can think of. My point it that the BP as it is today
|can be made better without adding complexity to it. I hope to show it
|through the following analysis:
|
|1. Recommendation 16.2.6.b combines the request stage and the data stage
|of the write. A target can't get an outstanding request in order to be
|able to prepare for the actual data (e.g. reading the appropriate block
|from a memory in order to change it with incoming data and write it back
|afterwards). This is a shortcoming for modeling timing.
|
|2. Recommendation 16.2.6.b in combination with rule 16.2.6.e prevent a
|read request to pass while a write data is executing. Thus, even for an
|in-order protocol with shared rd/wr channel, a target can't get an
|outstanding request in order to be able to prepare the data. This the
|timing to be pessimistic (for many transactions during simulation).
|
|3. Recommendation 16.2.6.c in combination with rule 16.2.6.f prevent a
|write response to pass while a read data is executing. Thus, even for an
|in-order protocol with shared rd/wr channel, an initiator can't get an
|acknowledgement in order to know it can free some inner space to be able
|to issue more outstanding requests. This also skews the timing to be
|pessimistic (for many transactions during simulation).
|
|
|Thus the following seems natural IMHO:
|
|1. Recommend that the write data is moved between END_REQ and
|BEGIN_RESP.
|
|2. Recommend that the read data is moved between END_REQ and BEGIN_RESP.
|This is natural for many protocols (unlike AXI) where the initiator asks
|the target for each read data word.
|
|3. If these two recommendations are changed why not make them a single
|RULE. Thus it will not happen (quoting Marcello):
|
|"Without them, it is unclear what component takes care of what part of
|the timing, and although I'm sure your models will be consistent among
|them, you could have chosen differently than I did, so our models would
|not have consistent timing (reads would take zero-time while writes 2x
|what they should). Notice that I say "consistent" timing and not
|"accurate", as accurate implies a reference that we don't have and we
|consciously decided not to have."
|
|BTW an AXI initiator can add its read timing to the timing annotation
|parameter when it returns the nb_transport (END_REQ) call so
|interoperability can be maintained as everybody wants even for this
|aspect of AXI.
|
|4. Can somebody convince me why the response exclusion rule 16.2.6.f is
|needed? It makes the code more complex, a PEQ management is needed, and
|it may slow down the simulation if this PEQ is actually used. My point
|was that there is no need for a master to be able to apply backpressure
|because it should not issue too many outstanding requests that it can't
|handle.
|
|Regards
|Yossi
|
|-----Original Message-----
|From: tlmwg@lists.systemc.org [mailto:tlmwg@lists.systemc.org] On Behalf
|Of Aldis, James
|Sent: Friday, January 07, 2011 12:22 PM
|To: Veller, Yossi; Robert Guenzel
|Cc: Marcelo Montoreano; Bart Vanthournout; john.aynsley@doulos.com;
|P1666 Technical WG; tlmwg@lists.systemc.org
|Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules
|
|
|Yossi,
|
| firstly what you say is not even true, because as we have discussed
|the things you thought were rules are in fact not obligatory. you can
|get
|a good approximation for AXI using BP if you interpret the phases
|slightly
|differently.
|
| secondly, why on earth would you find it surprising that a single TLM
|protocol is unable to maintain the same timing fidelity for all hardware
|protocols?
|
| thirdly, why would you _always_ advise your clients not to use BP, if
|it
|is pretty damn good in many cases (eg AHB)?
|
| fourthly, how do you imagine any kind of definition of BP/AT accuracy
|for a given set of rules,
|given that accuracy depands rather more on the models than the bus API,
|and
|that accuracy for AXI, APB, OCPa, OCPb, STBus, AHB, DDR, DDR2, SRAM,
|PCI,
|Wishbone, Unipro/Pie, PCIe, etc, etc, etc are all different and there
|are
|zillions of these things?
|
| fifthly, I'll bet you any money you like that in the 5% accurate AHB
|simulation you mention there are many many individual transactions which
|are modelled 100% innaccurately. it is completely unfair to compare an
|overall avarage with one specific directed test case.
|
| the BP is, as Robert said, designed to cover as many bus interfaces as
|possible "reasonably well". high-end bus interfaces with parallel rd
|and
|wr, interruptible or interleaved transactions, etc attract lots of
|attention
|but are not dominant. on an SoC with a couple of hundred components the
|vast majority aren't going to have parallel rd and wr busses. those
|that
|do are usually the components where a little extra work is invested
|anyway. therefore the BP design makes perfect sense. but wait, it's
|better than that - the BP can even do your example! (note that there
|_are_ bus interfaces more sophisticated than AXI out there, which the BP
|really can not do well). this was known when the BP was designed).
|
| i really do not understand why you think you have a problem.
|
|James
|
|
|
|>
|Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve
|Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

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