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

Yossi,

You still have a bus that only can handle 1 (BEGIN_RESP, END_RESP) interval for all initiators and targets that are connected to it while the rule says that the exclusion is only per socket.
So if you want a bus that is able to handle more of these response intervals you still can return END_RESP immediately to the target at time t=t1+319NS and pass the transaction upstream to the initiator.

I do not see a reason to remove the rule, it seems to me that you see a limitation where there is none…

Bart

From: Veller, Yossi [mailto:Yossi_Veller@mentor.com]
Sent: Thursday, January 06, 2011 5:36 PM
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

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