RE: Minor TLM enhancements/fixes

Jerome,

I think you have misunderstood the intent of my email. This is completely my fault, because I wrote it in a hurry in our race-against-time, and did not properly explain myself.

I am fully aware that the list of rules below is not your proposal. Neither am I making a new proposal. Rather, I was thinking "what if" we went all the way and revised the base protocol to have a new set of rules. What would those rules look like, and how we might then retrofit them into the current legacy codebase?

Having said that, I was thinking that even with your proposal, we have a choice as to how to present this in the LRM. Clearly C) is not compatible with your proposal, but we could chose between something like A) or B).

I hope this is clearer.

Cheers,

JohnA

-----Jerome CORNET <jerome.cornet@st.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Jerome CORNET <jerome.cornet@st.com>
Date: 12/07/2010 10:14AM
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
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, and is
believed to be clean.