RE: Minor TLM enhancements/fixes

Jerome, John,

Going along with John’s proposed options I think they should reflect the following:

Option A) is not what Jerome proposed, since there is a minimal non-ignorable handshake in his proposal (which is the cause for the backward compatibility issue I’ve been complaining about) and which I don’t find back in the option description, but I guess the intention was that this reflects Jerome’s original proposal. It assumes that the payloads are clean and that the “ignorable attributes for DMI/Debug” remain untouched on the transaction chain.

Option B) is basically lifting straming_width and byte_enables in the Debug and DMI calls to the level of the transport call (you’re not obliged to use them but if you do everyone needs to handle them). This clearly causes a major backward compatibility problem.

My understanding of option C) is that it is more like A) but where the backward compatibility issue gets resolved through a standardized ignorable extension that is used to enable a handshake between all components in the transaction chain, indicating they understood the intended use of streaming_width or byte_enables. This sounds like how I would expect this to be resolved in the first place, but requires us to come up with the definition of this extension….

I think there is still Option D): do nothing.

My preference is D) and then C). It’s obvious that I have an even bigger problem with B) than with A) since it requires all existing models to be modified.

Bart

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Jerome CORNET
Sent: Tuesday, December 07, 2010 11:13 AM
To: john.aynsley@doulos.com
Cc: P1666 Technical WG
Subject: RE: Minor TLM enhancements/fixes

John,

I understand better this email, although it is a new proposal that slightly departs from mine.
Comments and vote (in the interest of converging) below.

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, December 07, 2010 6:33 AM
To: john.aynsley@doulos.com
Cc: P1666 Technical WG
Subject: RE: Minor TLM enhancements/fixes

Folks,

Just to anticipate where this might lead, if we were to change the base protocol, the revised rules would look something like the following:

>> * For DMI and Debug, the initiator shall initialize the response status attribute to TLM_INCOMPLETE_RESPONSE, and shall check the response status on return from get_direct_mem_ptr. An error response shall imply that DMI or Debug have failed, and gives some indication of the reason for failure

With my proposal, an error response in the response status does not imply that DMI and Debug failed, as the existing and backward compatible way of detecting error is: for DMI by the return value false of the interface method call (which means “no DMI support”, but could have been caused by say, a routing error), for Debug the fact that the number of bytes returned by the debug interface is different from the one expected (which again can have been caused by an error).
In *my* proposal the response status *can* be checked if DMI access returned false, or if the Debug return value is not the one expected.
It does not determine alone whether an error occurred or not.

In my proposal, a pre-IEEE TLM-2 standard can perfectly leave the response status to TLM_INCOMPLETE_RESPONSE, which is not to be understood by the initiator as a cause for error, and guarantees backward compatibility.


* For DMI and Debug, an interconnect or target shall set the response status to TLM_OK_RESPONSE if it is able to process the DMI or Debug request successfully, or otherwise to one of the six error responses

In my proposal, the interconnect and the target are not obliged to do so, hence backward compatibility.

* For Debug, the initiator may set the byte enables, or shall initialize the byte enable pointer and byte enable pointer to 0 if byte enables are not used

Agreed.

* For Debug, the initiator may set the streaming width, or shall initialize the streaming width to equal the data length if streaming width is not used

Agreed that it would be more consistent with regular transport, but again, this is not my proposal. The initiator can leave the streaming width to its default value (0) and a streaming width aware target cannot complain about it, which is backward compatible with pre-IEEE TLM-2.

* For Debug, if the byte enable pointer is non-zero the target shall be obliged either to use the byte enables or to generate a standard error response if it unable to do so

With my proposal, a pre-IEEE TLM-2 target can leave the response status to TLM_INCOMPLETE_RESPONSE, which shall indicate that the byte enable was not understood. Only targets that are aware of byte enable should set the response status to TLM_OK_RESPONSE to indicate that they indeed understood and supported the transaction.

* For Debug, if the streaming width is less than the data length, the target shall be obliged to use the streaming width or to generate a standard error response if it unable to do so
I would prefer something less strong in the wording (there is no obligation to support this feature, as you can return an error to indicate so), but I agree.


What would be the status of the revised rules in the LRM? Here are three suggestions:

A) Mere suggestions for ways in which a component can use the generic protocol attributes for DMI and Debug, understanding that components are still free to ignore those attributes. I think this is the current proposal

B) Strong recommendations: all new components should obey these new base protocol rules, with the anticipation that the old rules may be deprecated in due course

C) Rules that shall be obeyed if this base protocol variant is used, in which case an initiator using the new protocol variant shall add a standard extension to the transaction for DMI and Debug, and an interconnect or target that recognizes the new protocol variant shall handshake with the initiator by modifying a flag in the extension.

If we want the community to move to this revised base protocol, I suggest option A) would be the weakest choice, and option C) the strongest.

I am not against your proposal of rules at the beginning of this email. I just want to make it clear that this is stronger and less backward
compatible than mine.
In the state of the proposal, I would however vote for (B) as it is going in the right direction.


(A) is not my proposal, and (C) is the extension one, which represents no progress w.r.t what we are already doing internally and to the interoperability in general.



Jerome


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