RE: TLM extensions - status

This is very promising! Should satisfy both objectives - Jerome's enhancement and the backward compatibility concerns.

-Bishnupriya
________________________________
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 8:39 PM
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.