RE: TLM extensions - status

John, fully in agreement with Bart’s additional comments below.

Jerome


From: Bart Vanthournout [mailto:Bart.Vanthournout@synopsys.com]
Sent: Friday, December 10, 2010 10:30 AM
To: john.aynsley@doulos.com; Bart.Vanthournout@synopsys.COM
Cc: Jerome CORNET; P1666 Technical WG
Subject: 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

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