RE: TLM extensions - status

From: Stuart Swan <stuart@cadence.com>
Date: Wed Dec 08 2010 - 07:22:02 PST

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.
Received on Wed Dec 8 07:22:33 2010

This archive was generated by hypermail 2.1.8 : Wed Dec 08 2010 - 07:22:35 PST