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.