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

Hi all,

 

I think that it is time to wrap up.

 

The problem is that some TLM simulations do not provide the modeling of the throughput and latency that the user would expect from out-of-order protocols that were designed to maximize these properties (so the OCP configuration does not count). A bus with separate write and read data channels should be able to finish both transactions in 320 NS and not 640 NS. On a bus with shared write and read data channels, one of the transactions would finish in 320 NS. I contend that this has the potential to surprise, perplex and annoy users.

 

You cannot blame the models because, apart with complying with the TLM2 rules, they have to adhere to applicative timing requirements.

· The model writer should not change the defined timing of the target in order to overcome the problem that was demonstrated (like Marcelo wrote). Moreover why use an out-of-order protocol if you have to reply in order.

· The bus has an arbitration policy that is defined regardless of the TLM rules. This arbitration may dictate sometimes forwarding one initiator and sometimes the other e.g. in order to prevent starvation. So the bus is even deterministic and smart but the result will be timing that is sometimes long and sometimes short.

 

What exacerbates the problem is that models followed the TLM rules and recommendations to the letter. If you think that rules or recommendations will lead the users to problems don’t give them.

 

If your standard is designed to support timing at a certain level of accuracy in an interoperable way it has to have rules that ensure it. Leeway and recommendations will not get you there (and Marcelo agrees with me).

 

Don’t blame the example: it did not use timing annotation, it considers the TLM rules only on the connection between the bus and the target etc. I didn’t find any problems with the logic there.

 

Don’t blame me that I just want the BP to be an AXI, out-of-order protocols are not just AXI.

 

Hence “It is the rules!”

 

So I can think of the following options for us to do:

 

1. Declare that the BP disallows out-of-order protocols and incur the overhead of reordering everywhere and that modern buses are excluded.

2. Declare that there is no problem, but then I would recommend that the example is added to the LRM in order to warn the users so that they expect the behaviors demonstrated above and explain why, with the existence of viable alternatives, we have chosen to stick to the rules.

3. Change the rules.

 

Regards

Yossi

 

From: Marcelo Montoreano [mailto:Marcelo.Montoreano@synopsys.com]
Sent: Thursday, January 06, 2011 9:42 PM
To: Veller, Yossi; 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 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.