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

HI Yossi,

The rules spell out how to account for the socket utilization such that flow control is possible and meaningful. I1 should not send another request to B between t1 and t1+310, as the socket is being used to transfer the write data. The rules don’t say that activity between I1-B should affect I2 - B.

B could have been smarter and given that there were 2 requests at t1, prioritize I2, as it is a read.

If T was a good peripheral model, it would have responded at 319 GP1(BEGIN_RESP), as it is an older transaction, before doing GP2(BEGIN_RESP), but it is totally ok for T to do it the way you describe. Maybe it takes some time to write the actual data to storage and the peripheral you are using reflects that.

Either of those would allow the initiators to finish their transaction earlier.

I don’t see anything wrong on the rules, and I don’t think they are superfluous. 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.

Blindly coding to follow the rules will not get you a decent component or system. There is too much leeway in there. Think of what you want to achieve with the model, then code it without breaking BP rules. You probably will have to compromise and stay with BP, or create your own, incompatible protocol.

Regards,

Marcelo.-

From: tlmwg@lists.systemc.org [mailto:tlmwg@lists.systemc.org] On Behalf Of Veller, Yossi
Sent: Thursday, January 06, 2011 8:36 AM
To: Bart Vanthournout; john.aynsley@doulos.com; robert.guenzel@greensocs.com
Cc: P1666 Technical WG; tlmwg@lists.systemc.org
Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules

Hi Bart,

I changed the example to reflect this chain of mails.

t= t1 I1 sends GP1(BEGIN_REQ) to B
                           B passes the GP1(BEGIN_REQ) to T
                           T computes that the written data takes 310 NS (because of the recommendation of rule 16.2.6 b)
                                    and schedules an inner event notification to t1+310 NS.
                           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+310 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 END_REQ and B sends GP2(END_REQ) to I2.
                           T schedules an inner event notification to t1+319 NS.
t= t1+319 NS T sends GP2(BEGIN_RESP) and B passes it to I2.
                           I2 computes that the read data takes 311 NS (because of the recommendation of rule 16.2.6 c)
                                   and schedules an inner event notification to t1+640 NS.
t= t1+640 NS I2 sends GP2(END_RESP) and B passes it to T (and the read finishes)
                          T sends GP1(BEG_RESP) to I1 which replies with TLM_COMPLETED (and the write finishes)

The outcome is that in a perfectly good TLM2.0 system two transactions each of which should have taken 320 NS, finish BOTH after 640 NS. This seems to me a distortion of the timing and the removal of the response exclusion rule will fix this scenario.

Regards
Yossi

From: Bart Vanthournout [mailto:Bart.Vanthournout@synopsys.com]
Sent: Thursday, January 06, 2011 4:35 PM
To: Veller, Yossi; john.aynsley@doulos.com; robert.guenzel@greensocs.com
Cc: P1666 Technical WG; tlmwg@lists.systemc.org
Subject: RE: [tlmwg] Revisit of the TLM2.0 phases rules


Yossi,

I just started reading through this chain of mails so sorry but I want to get back to the example, I think you treat the protocol as an end-to-end protocol while the rules only apply per socket.

t= t1 I1 sends GP1(BEGIN_REQ) to B
                                B passes the GP1(BEGIN_REQ) to T
                                T computes that the written data takes 310 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+310 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 END_REQ and B sends GP2(END_REQ) to I2.
t= t1+319 NS T sends GP2(BEGIN_RESP) and B passes it to I2.
                                I2 computes that the read data takes 311 NS (because of rule 16.2.6 c) and waits.
t= t1+320 NS T sends GP1(BEGIN_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 read finishes)
                                B sends the GP1(BEG_RESP) to I1 which replies with TLM_COMPLETED
                                B sends the GP1(END_RESP) to T (and the write finishes)

Rule 16.2.6.f) says: For the base protocol, a target or interconnect component shall not respond to a new transaction
through a given socket with phase BEGIN_RESP until it has received END_RESP from the upstream component for the immediately preceding transaction or until a component has completed the previous transaction over that hop by returning TLM_COMPLETED. This is known as the response exclusion rule.


To me that means that the example is wrong at t = t1+320 NS, the target cannot send GP2( BEGIN_RESP) over its TLM2 socket since it did not receive an END_RESP for GP1.
In order to accomplish what you are looking for (I think) the bus to respond with a END_RESP for GP1 at time t =t1+319NS and pass the BEGIN_RESP to I1. This allows the target to continue with an BEGIN_RESP for GP2 and the bus can also forward to initiator I2 since the response exclusion rule applies per socket.

So I see the following happening:

t= t1 I1 sends GP1(BEGIN_REQ) to B
                                B passes the GP1(BEGIN_REQ) to T
                                T computes that the written data takes 310 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+310 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 END_REQ and B sends GP2(END_REQ) to I2.
t= t1+319 NS T sends GP2(BEGIN_RESP) and B returns GP2(END_RESP) to T, to allow it to continue
B passes GP2(BEGIN_RESP) to I2.
                                I2 computes that the read data takes 311 NS (because of rule 16.2.6 c) and waits.
t= t1+320 NS T sends GP1(BEGIN_RESP) and B returns GP2(END_RESP) to T, to allow it to continue
                                B passes GP1(BEGIN_RESP) to I1 which replies with TLM_COMPLETED
t= t1+640 NS I2 sends GP2(END_RESP) to B (and the read finishes)


At least this is my reading of the standard….

Bart

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