RE: TLM extensions - status

Stuart,

We are on the same page.

Users can do this RIGHT NOW with an ignorable extension but doing so does not provide interoperability, which I think was Jerome's objection

We could defined a standard extension in the LRM with the same effect, and that would provide interoperability. But a "standard extension" is a bit ugly

Hence my proposal for a new GP attribute.

I also had possible endianness changes in mind for the future (an issue I take seriously)

We would have to decide whether components are obliged to set the new flag for all transactions, or only for DMI and Debug.

To allow for future expansion, having two attributes (or some other more sophisticated scheme) might be an idea. A handshake is necessary. One attribute could signal the level of the initiator, and a second attribute the level of whatever component is playing the role of target (which could be an interconnect component in its day job).

John A

-----Stuart Swan <stuart@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "jerome.cornet@st.com" <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, Stan Krolikoski <stanleyk@cadence.com>, "bartv@synopsys.com" <bartv@synopsys.com>
From: Stuart Swan <stuart@cadence.com>
Date: 12/08/2010 03:22PM
Subject: RE: TLM extensions - status

         
  John-
   
  I think this is a very interesting way to proceed, but I still need to mull it a bit.
   
  Thinking out loud again – the technical rationale for an approach like this as opposed to using extensions is that this approach allows the initiator to know for certain if the response status is valid and fully filled in – e.g. to reliably detect routing errors.
   
  Conceiveably this mechanism might also be used in the future to handle different endianness schemes (ie the Jakob vs James stuff).
   
  Should there be 2 separate attributes – one set by the iniatiator, and one set by the target, so that we don’t mix the version info?
   
  Thanks
  Stuart
   
  
  From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
 Sent: Wednesday, December 08, 2010 7:09 AM
 To: jerome.cornet@st.com; systemc-p1666-technical@eda.org; Stan Krolikoski; bartv@synopsys.com
 Subject: TLM extensions - status
     
  All,
 
 Combining the votes related to Jerome's TLM changes, I have seen
 
 YES - Jerome, Stuart, Bisnupriya, Mac, Philipp
 NO  - Bart, John
 
 
 How about we add a new attribute to the generic payload
 
 * Default value 0 => old initiator
 * Value 1 => (set by initiator) new initiator, byte enable/width/response fields are properly set for DMI/Debug
 * Value 2 => (set by target) new initiator & new target, target has properly set response status
 
 (There will need to be a new TLM-2.0.2 kit, so existing code will need to be recompiled anyway.)
 
 That would resolve all my backward compatibility concerns (because a new target would know it had a transaction from a new initiator) and would go futher in that it would allow a new initiator to rely on the full range of response status values.
 
 Would that work for everyone, or am I just stirring mud?
 
 Thanks
 
 John A
 
 
  
 --
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.
    

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