RE: TLM extensions - status

What if we put in a rule that requires to reset this new flag whenever you use it? In this case a new initiator that wants to use the additional attributes would be required to ‘clean-up’ after the debug or DMI call.

I still think the extension approach is better, but if we want to land in the next couple of days we’ll have to be very practical.

Bart

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, December 08, 2010 10:01 PM
To: Philipp A. Hartmann
Cc: john.aynsley@doulos.com; Stuart Swan; Bart Vanthournout; Jerome CORNET; stanleyk@cadence.com; P1666 Technical WG
Subject: Re: TLM extensions - status


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 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.
>
>
>


--
Philipp A. Hartmann
Hardware/Software Design Methodology Group

OFFIS Institute for Information Technology
R&D Divis

-Your data has been truncated.

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