Re: TLM extensions - status

I also like this with a twist. The new attribute should be style something along the lines of protocol "version" or "type" or "flavor" . Longer term we could discuss the proper way to use this to identify base protocol evolution.

For user or vendor defined protocol extensions, I prefer the notion of using BP extensions; although, standardizing versioning of protocols might be worth some discussion.

So I am in favor of the notion.

On Dec 8, 2010, at 9:22 AM, Stuart Swan wrote:

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

------------------------------------------------------
David C Black, System-Level Specialist
XtremeEDA USA Corporation http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL design assurance needs)
Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609

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