RE: TLM extensions - status

Adding this GP attribute is not an extension mechanism. It only covers a few use cases, roughly speaking the same use cases as ignorable extensions. And agreed we could solve the current issue with a standard extension. I was just trying to unblock the impasse.

John A

-----Bart Vanthournout <Bart.Vanthournout@synopsys.com> wrote: -----
To: Stuart Swan <stuart@cadence.com>, "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" <Bart.Vanthournout@synopsys.COM>
From: Bart Vanthournout <Bart.Vanthournout@synopsys.com>
Date: 12/08/2010 03:59PM
Subject: RE: TLM extensions - status

 
Stuart,
 
This is why the extension mechanism is the preferred way of dealing with this type of issues, preferably each variation/extra feature gets handled through its own extension. If we would want to handle different endianness schemes I would prefer a dedicated extension for that…
 
Bart
 

From: Stuart Swan [mailto:stuart@cadence.com]
Sent: Wednesday, December 08, 2010 4:22 PM
To: john.aynsley@doulos.com; jerome.cornet@st.com; systemc-p1666-technical@eda.org; Stan Krolikoski; bartv@synopsys.com
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.