RE: transport_dbg and TLM_IGNORE_COMMAND

John,

I buy your argument. This would indeed stay “aligned” with the general spirit
around ignorable stuff.

Thus, I am fully OK with your proposal of returning whatever value the user needs to
return.

Regards,

Jerome


From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, December 03, 2010 6:16 AM
To: Jerome CORNET
Cc: john.aynsley@doulos.com; P1666 Technical WG
Subject: RE: transport_dbg and TLM_IGNORE_COMMAND

Jerome, All,

I believe we did discuss this issue in the TLM-WG, albeit indirectly in the context of ignorable phases. We made the point that in general in the presence of an ignorable phase or ignorable extension or TLM_IGNORE_COMMAND, it is dangerous to use regular attributes of the GP to signal that an ignorable phase/attribute/cmd has been acted upon, because the executor may not be aware of the presence of OTHER ignorable attributes/cmds that it does NOT recognize. Specifically, in your case, a target could set the return value from transport_dbg to some specific value to signal that it had understood and executed a particular extended command, but this could mislead some other component in the chain which was awaiting a response to a DIFFERENT extended command, which the target did NOT recognize. Based on this kind of argument, I believe we decided that any response to an ignorable extension/phase/cmd had to be through an extension in order to reduce the possibility of confusing the responses to different extended commands.

I am not claiming that this is an entirely conclusive argument, but I believe this is where the TLM-WG stood on this discussion.

John A

-----Jerome CORNET <jerome.cornet@st.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
From: Jerome CORNET <jerome.cornet@st.com>
Date: 12/02/2010 04:16PM
Subject: RE: transport_dbg and TLM_IGNORE_COMMAND
John,

sorry again for the late response.

I am fine with your answer, as the goal of my request was to clarify that part in the standard.

I have a different proposal, but I am not pushing strongly for it to be adopted:


Return 0 if the IGNORE command was “ignored” successfully

Return any non-zero value if the IGNORE command together with the associated extension

was understood by the target.


Any comments, in particular on backward compatibility is welcome.

Jerome


From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, December 02, 2010 3:54 AM
To: Jerome CORNET; systemc-p1666-technical@eda.org
Subject: transport_dbg and TLM_IGNORE_COMMAND

Jerome, All,

Let's see if we can deal with the easier issues.

Your original 4th point was about the value returned from transport_dbg for TLM_IGNORE_COMMAND. My answer was that an application is already free to return whatever value it likes without breaking the base protocol, although I would agree that is a matter of interpretation, and the LRM wording could be made more explicit.

In other words, TLM_IGNORE_COMMAND says that the target does not perform a BP read or write, but is free to do something else. The value returned from transport_dbg is tightly defined for read or write, but if the application is executing an extended command, the target is free to choose the return value.

Does that meet your requirement? Is everyone else okay with that?

Thanks,

John A

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