RE: TLM extensions - status

Jerome, Bart,
 
 Great! This proposal overcomes my objections re. backward compatibility.
 
 I will spell out this proposal a bit more fully, then put it to the group for an informal vote.

 John A

-----Jerome CORNET <jerome.cornet@st.com> wrote: -----
To: Bart Vanthournout <Bart.Vanthournout@synopsys.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Jerome CORNET <jerome.cornet@st.com>
Date: 12/10/2010 09:44AM
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: 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.