RE: TLM extensions - status

Ok, I think I have now understood, my confusion was due to the fact that our implementation internally
does not work the way you are thinking about pools; pool locality is in our opinion very important for the
future, but anyway, this is not point).

So, let us be specific:

- do we agree that a pool of transaction cannot be shared between multiple different
vendor IPs using TLM-2?


- in the contrary, I understand that you are thinking to a situation where multiple initiators
of the same vendor may share the same transaction pool, with one initiator being “old” and the
other one being “new”. Am I right?

In this case, I agree we have got a problem of payload reinitialization because the old initiator
may reuse a payload which contain a version attribute left to 2.
But this is not a backward compatibility problem, do we agree?
A vendor whose initiators are all “old” that does not have the problem,
a vendor whose initiators are all “new” that does not have the problem.

But then, I agree mixing both is not very convenient, unless you use different pools for old and new
initiators (which in my mind is reasonable, but some may disagree; please speak up!)

So indeed, this means that a “new” initiator would be responsible for reinitializing the version attribute to 0
before releasing the transaction. I agree that it would be beneficial to do that automatically in the payload,
although this is a convenience, it is not necessary to the proposal.

For non-memory managed transactions, it is not unreasonable to require the initiator to clear the flag, isn’t?

Jerome



From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, December 09, 2010 4:30 PM
To: Jerome CORNET
Cc: Bart Vanthournout; john.aynsley@doulos.com; Philipp A Hartmann; stanleyk@cadence.com; Stuart Swan; P1666 Technical WG
Subject: RE: TLM extensions - status

Jerome,

WHOOPS! That point is central to the backward compatibility argument, so perhaps we have been talking at cross-purposes all along.

A new initiator will reset the flag, but an old initiator will not reset the flag because it does not know it exists. Why does the the old initiator not get a new transaction with the flag at its default value of 0 anyway? Because it may be getting the transaction from a pool, where the transaction attributes will have values left over from a previous life. Hence the recent proposals for mechanisms to automatically reset the flag (and why auto extensions would have been an out-of-the-box solution if only a memory manager were mandated, which it is not).

John A

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