Re: Minor TLM enhancements/fixes

My vote would be "Yes", please add the new rules and go for a strong
recommendation (B).

  I think, if we'd add a TLM_DMI_DBG_OK_RESPONSE (or separate
TLM_DMI_OK_RESPONSE, TLM_DBG_OK_RESPONSE), we could even signal a
compliance to the new rules via the "new" response status (if the
initiator looks for it).

Greetings from Oldenburg,
  Philipp

On 07/12/10 06:32, john.aynsley@doulos.com wrote:
> 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
>
> * 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
>
> * 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
>
> * 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
>
> * 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
>
> * 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
>
>
> 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.
>
> John A

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany · http://www.offis.de/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.