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

* 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)

* "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)

* 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
 
 * New targets may set the DMI/Debug response status to ANY value (?), but ONLY if the new attribute is non-zero.
 
* 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

Is that the idea?

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.