RE: TLM extensions - status

John,

this is the idea.

Regards,

Jerome


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

* 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

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