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

IMHO the scenario you describe does not show that the rules are broken.
It's the target that might be broken.
Or it's me who didn't fully understand the problem.

I'll try to explain me view:

T sends GP1(END_REQ) at t1+320ns. By doing that it indicates
that it wants to insert a delay between END_REQ and BEGIN_RESP
(otherwise it would directly do GP1(BEGIN_RESP) )

The target knows what it did. Now it gets GP2(BEGIN_REQ).
If the target now returns UPDATED(BEGIN_RESP) it _knows_
that it now moves the RESP of GP1 _behind_ the RESP of GP2
(because it now assigns the RESP channel to GP2).
If it does not want to do that it can either return TLM_ACCEPTED
and finish GP1 first (by sending BEGIN_RESP), or return TLM_UPDATED(END_REQ)
and finish GP1 afterwards as well.

You say:
>
> The TLM2.0 base protocols rules created a scenario where two
> concurrent reads and writes of 320 NS took both 640 NS (this should be
> impossible).
>
There is no BP rule that forces T to do what you describe.
And I do not think that it should be impossible. If the target wants
to establish such a link between GP1 and GP2 it should be allowed
to do so. But it can decide to avoid/reduce the link like that:

t= t1 I1 sends GP1(BEGIN_REQ) to B
B passes the GP1(BEGIN_REQ) to T
T computes that the written data takes 320 NS (because of rule 16.2.6 b)
and waits.
I2 sends GP2(BEGIN_REQ) to B, B queues it in a PEQ (because of the
BEGIN_REQ rule 16.2.6 e).
t= t1+320 NS T sends GP1(BEGIN_RESP) and B passes it to I1
I1 returns TLM_COMPLETED (seen both by B and T). GP1 is DONE.
Then B takes GP2(BEGIN_REQ) from the PEQ and calls T.
T returns TLM_UPDATED and changes the phase to BEG_RESP and B send
GP2(BEG_RESP) to I2.
I2 computes that the read data takes 320 NS (because of rule 16.2.6 c)
and waits.
t= t1+640 NS I2 sends GP2(END_RESP) and B passes it to T. GP2 is DONE.

Now at the target side both GP1 and GP2 last 320 ns. For I2 GP2 lasts
640 ns but that is due to
the fact that GP1 and GP2 are scheduled by B.

I agree that there is the problem of preemption and interleaving,
but the question is if that is something that AT abstracts away or not?
I must confess that I am not sure about the answer to that question.

Due to the BEGIN_REQ rule preemption is not possible with another
BEGIN_REQ.
But how about ignorable phases TRY_PREEMPT?
After GP1(BEGIN_REQ) an initiator/interconnect can try a preemption by
sending GP1(TRY_PREEMPT) and if it gets back TLM_COMPLETED
the preemption was successful if it gets back TLM_ACCEPTED the target
is unable to preempt GP1. Should be BP compatible.

For interleaving I'd say that is something that is abstracted away at
the AT level.

best regards
Robert

Veller, Yossi wrote:
>
> During the Review of the Draft LRM I revisited the TLM2.0 as the new
> addition to the standard and found out the following:
>
> Let us look at two initiators I1 and I2 connected to a bus B and target T.
>
> I1 writes to T a burst whose data transfer should take 320 NS and
>
> I2 reads from T a burst whose data transfer should take 320 NS at the
> same time (t1).
>
> Let us denote the generic payload (GP) from I1 GP1 and the GP from I2 GP2
>
> t= t1 I1 sends GP1(BEGIN_REQ) to B
>
> B passes the GP1(BEGIN_REQ) to T
>
> T computes that the written data takes 320 NS (because of rule 16.2.6
> b) and waits.
>
> I2 sends GP2(BEGIN_REQ) to B, B queues it in a PEQ (because of the
> BEGIN_REQ rule 16.2.6 e).
>
> t= t1+320 NS T sends GP1(END_REQ) and B passes it to I1 then B takes
> GP2(BEGIN_REQ) from the PEQ and calls T.
>
> T returns TLM_UPDATED and changes the phase to BEG_RESP and B send
> GP2(BEG_RESP) to I2.
>
> I2 computes that the read data takes 320 NS (because of rule 16.2.6 c)
> and waits.
>
> T sends GP1(BEG_RESP) and B pushes it into the PEQ (because of the
> BEGIN_RESP rule16.2.6 f).
>
> t= t1+640 NS I2 sends GP2(END_RESP) and B passes it to T (and the
> write finishes)
>
> B sends the GP1(BEG_RESP) to I1 which replies with TLM_COMPLETED
>
> B sends the GP1(END_RESP) to T (and the read finishes)**
>
> The TLM2.0 base protocols rules created a scenario where two
> concurrent reads and writes of 320 NS took both 640 NS (this should be
> impossible).
>
> Other scenarios show that relying on simulation order both read and
> write can finish after 320 NS or that either one can finish after 320
> NS and the other one after 640 NS. All the above happens because there
> is an artificial linkage between the request stage of the read and the
> data phase of the write (they use the same phases) and another
> artificial linkage between the acknowledge stage of the write and the
> data phase of the read.
>
> IMHO these scenarios show that the rules are broken and have to be fixed.
>
> Moreover these rules don’t support the following:
>
> 1. Preemption where a higher priority transaction can abort a lower
> priority long burst of data in order to transmit its data and let the
> aborted transaction continue.
>
> 2. Interleaving of the data of a slow burst with data of other bursts.
>
> The fix cab be the following:
>
> 1. Specify that the BEGIN_REQ -> END_REQ stage is the address passing
> stage.
>
> 2. Retain the BEGIN_REQ rule (16.2.6 e) that allows a target to slow
> down upstream components.
>
> 3. Specify that the END_REQ -> BEGIN_RESP stage is the write data
> passing stage.
>
> 4. Remove the BEGIN_RESP (rule16.2.6 f). An initiator should not
> anyways issue too many outstanding requests that it can’t handle.
>
> This fix will also support Preemption and Interleaving.
>
> Regards
>
> Yossi
>

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