RE: TLM extensions - status

While I think the idea of a protocol version field in the payload (along the lines of David Black's previous comment) is appealing at some level - but I feel we are rushing in pushing one of the more recently suggested solutions (last 12 hours) into the standard without full and proper consideration and a broader input from stakeholders.

I feel this should be left to the TLM working group for a future release of TLM 2.1 or TLM 3.0 that then would be included in a subsequent IEEE standard update.

I will vote no on this change.

Best regards,

Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Thursday, December 09, 2010 8:22 AM
To: John Aynsley
Cc: Philipp A. Hartmann; Stuart Swan; Bart Vanthournout; Jerome CORNET; stanleyk@cadence.com; P1666 Technical WG
Subject: Re: TLM extensions - status
The usual trick would be to use an auto extn (cleared by mm) which could point to a heap object if we wanted a handshake with the target, or to a static extension object for efficiency (with free() overridden) if we simply wanted to flag a new-style init
John A
-original message-
Subject: Re: TLM extensions - status
From: "John Aynsley" <john.aynsley@doulos.com>
Date: 08/12/2010 13:00
Good point. The new init would be obliged to reset the flag, which could be done in the mem mgr, but it is not v robust. An extension would be safer, or Erics proposal...
John A
-original message-
Subject: Re: TLM extensions - status
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 08/12/2010 08:15
John, all,
I also think, that the addition of versioning the BP might be a good
path for the future. But I'm a bit hesitant to embrace this in this
short time frame we have left now.
I fear the following issues:
1) How can the addition of an additional field (which needs to be
properly initialised when reusing payload objects) solve the
backwards compatibility issue?
If we have a shared transaction pool for multiple initiators,
the newly added attribute may be wrong, if not explicitly set
by an "old" initiator. Which does not know anything about it.
So it's even worse, since not just the "poorly coded" initiators
are affected.
2) We break API compatibility with OSCI TLM 2.0 (not only binary
compatibility due to a new kit). This leads to preprocessor
clutter in many models, that intend to support both versions.
3) Do we actually catch all other caveats with the proposed
versioning, if we define it in a quick shot now?
I don't want to block any consensus here. I'm just concerned, that we
do more harm than good, if we're not careful here. In fact, I think
potential missed corner cases here may cause more maintenance effort
down the road, than just fixing/documenting existing "poorly coded" models.
Am I missing something?
Greetings from Oldenburg,
Philipp
On 08/12/10 16:54, john.aynsley@doulos.com wrote:
> 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
-Your data has been truncated.
--
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.