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

My thoughts about that are

> 1. Recommend that the write data is moved between END_REQ and
> BEGIN_RESP.
>
I could live with that.

> 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.
>

That seems to be an inversion of controlflow. both END_REQ and BEGIN_RESP
are controlled by the slave. But in general the duration of the response
phase is controlled by the initiator. meaning BEGIN_RESP should mark the
timing point when the target is ready start "producing", while end resp
indicates when the initiator is done consuming. If the data of a read is
passed between END_REQ and BEGIN_RESP what exactly is BEGIN_RESP referring
to? The very last beat in aburst? Is it somethign artificial? Or is it an
end-of-bus-occupation marker (like Sl_rdComp in PLB?).

For reads I think data passing should happen between BEGIN_RESP and END_RESP.

> 3. If these two recommendations are changed why not make them a single
> RULE.

What if a bus does not have a separate data phase (i.e. data is passed
together with req), such as in most simpler peripheral busses like APB,
OPB, some OCPs, and DCR. There is no "between END_REQ and BEGIN_RESP in
such busses. So it should stay a recommendation it can't be a rule.

>
> > 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.

An initiator sending out three reqs does not imply it can handle three
(overlapping) responses at a time. An initiator could send out three reqs
to different memory-mapped I/O-Blocks which may return out-of-order, but
it might still want to process only one of the resps at a time. To do that
it needs to be able to stall the other resps, or put them on hold.
Furthermore, if the response exclusion rule is dropped, END_RESP becomes
meaningless as it has no guaranteed effect. No matter what the initiator
does it will get the next BEGIN_RESP. No matter what. By that the
pipelining of REQ and RESP becomes unusable if an initiator only wants to
process a single resp at a time. It will have to wait for a resp before
issuing the next req.

Now we could define command dependent response exclusion rules, but as
jakob hinted, there are certainly people that will argue against command
based exclusion rules just like you are currently arguing against a
general exclusion rule.

That was my view.

best regards
  Robert

> 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.