RE: TLM extensions - status

Btw: as you could assume I agree that the backwards compatibility issue is resolved with John’s proposal. Whether we add the attribute through the extension mechanism or through a payload attribute isn’t a big deal, I understand that adding it to the payload will make it clearer that this is part of the standard. I would go for the original proposal and have the attribute dedicated to this feature, it is still an ignorable feature in the end…. (so not a ‘version’ label)

On the other hand: adding endianness to a TLM2.0 related topic is a guarantee for an endless discussion… here it just shows that there might be more of these ignorable features that we will want to add… which is why I prefer to use the extension mechanism… but I can live with the latest proposal, this time around.

Bart

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, December 08, 2010 5:05 PM
To: Bart.Vanthournout@synopsys.COM
Cc: Bart.Vanthournout@synopsys.COM; Jerome CORNET; john.aynsley@doulos.com; stanleyk@cadence.com; Stuart Swan; P1666 Technical WG
Subject: 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<http://www.mailscanner.info/>, and is
believed to be clean.

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