RE: TLM extensions - status

John,

What you describe is what I had in mind, comments below

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, December 10, 2010 3:46 AM
To: Bart.Vanthournout@synopsys.COM
Cc: Jerome CORNET; P1666 Technical WG
Subject: RE: TLM extensions - status

Bart, Jerome,

I am not certain I know what we are converging on. Is the following correct? (This is not a proposal; I am just checking whether we are on the same page.)

* We add a new attribute (or possibly two) to the GP
[BVt] would go for 1 (haven’t figured out yet why we would need 2)


* Hence we will add new public methods to the GP to get and set this attribute, which will be private

* It has a default value of 0 (or some other null value)
[BVt] we could use enums and use “MINIMAL_PAYLOAD” for this value


* "Old" initiators will not be aware of it, and hence will leave it at 0

* "New" initiators will set it be be non-zero, and we will define some protocol between new initiators and new targets for modifying this attributes (e.g. the new initiator sets it 1 and the new target sets it 2)
[BVt] we could use “FULL_PAYLOAD” and “FULL_PAYLOAD_ACCEPTED” for the other values


* New initiators are obliged to set the attribute back to zero at the end of the transaction lifetime

* We may perhaps automate this if a memory manager is present

* This will work with transaction pools regardless of what we assume about the number of pools and whether or not transactions are cleaned as they emerge from the pool

* New targets would process Debug transactions with BE and Streaming set, but ONLY if the new attribute is non-zero, and could use the full range of response status values to signal success/failure back to the initiator
[BVt] yep I would say they can use the full GP payload in the same way as in the transport API (just to avoid that we want to add more features later)


* New targets may set the DMI/Debug response status to ANY value (?), but ONLY if the new attribute is non-zero.
[BVt] same as above (again I guess there is a range of attribute combinations that wouldn’t make sense but I guess no initiator would try them..?)


* Old targets may receive DMI/Debug transactions with BE and Streaming set, but will probably ignore them. We are prepared to live with any risk that they actually interpret those attributes
[BVt] that and the fact that when a new initiator does a write debug to an old target using byte enables, it needs to take care that it doesn’t accidently overwrite any values…


Is that the idea?
[BVt] yes.


John A


-----Bart Vanthournout <Bart.Vanthournout@synopsys.com> wrote: -----
To: Jerome CORNET <jerome.cornet@st.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bart Vanthournout <Bart.Vanthournout@synopsys.com>
Date: 12/09/2010 04:15PM
Cc: Bart Vanthournout <Bart.Vanthournout@synopsys.COM>, Philipp A Hartmann <philipp.hartmann@offis.de>, "stanleyk@cadence.com" <stanleyk@cadence.com>, Stuart Swan <stuart@cadence.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: TLM extensions - status

To me it seems we’re converging, so I would hand it back to John to write this down in a proposal unless someone really wants to do this differently….

Bart

From: Jerome CORNET [mailto:jerome.cornet@st.com]
Sent: Thursday, December 09, 2010 4:48 PM
To: john.aynsley@doulos.com
Cc: Bart Vanthournout; Philipp A Hartmann; stanleyk@cadence.com; Stuart Swan; P1666 Technical WG
Subject: 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.