Revisit of the TLM2.0 phases rules

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.