RE: Minor TLM enhancements/fixes

Bart,

Sorry for the late response. You are right, I have pointed out section numbers but I have not been very specific on the actual
modifications.

So, let us be more specific and sort things by issue. I have tried to write a proposal of detailed modification; please
excuse my poor english in advance...

- For the capability to detect address errors on DMI Interface:

12.2.4.k: In the case of the base protocol, the initiator is not obliged so set any attributes of the generic payload aside from command, address, data length and data pointer, and the target and any interconnect may ignore all other attributes.
 However, a target/an interconnect may set the response status to a value different from TLM_INCOMPLETE_RESPONSE and TLM_OK_RESPONSE to provide complimentary information about the reason why the DMI request did not succeed. In particular, an interconnect may set the response status to TLM_ADDRESS_ERROR_RESPONSE to indicate that no target was present at the given address of the DMI request.
Note however, that an initiator receiving a transaction with TLM_INCOMPLETE_REPONSE or TLM_OK_RESPONSE cannot infer any fail or success of the DMI request based solely on this information, as the response status can be ignored altogether. Similarly, other attributes may be ignored. In particular, the DMI allowed attribute is only intended for use with the transport interface.

- For the streaming width, byte enable, response status and Debug Interface:

12.3.4.o: In the case of the base protocol, the initiator is not obliged so set any attributes of the generic payload aside from command, address, data length and data pointer, and the target and any interconnect may ignore all other attributes. In particular, the response status may be ignored. However:
 - an initiator may additionally set the streaming width and/or byte enable attributes of the generic payload. In such case, as with the transport interfaces, there is no guarantee that the target will support these attributes. The initiator can infer that such transactions with byte enable/streaming width has been successfully executed if and only if the response status after the call is set to TLM_OK_RESPONSE. In all other cases (notably if the response status is left to TLM_INCOMPLETE_RESPONSE), there is no guarantee that the transaction with streaming width/byte enable has been successfully executed.
- a target that supports the streaming width or byte enable attribute shall return TLM_OK_RESPONSE if it can handle the transaction. Other targets may leave the response status unchanged or set to a different value. A target shall not complain upon reception of a generic payload with the streaming width or byte enable attributes left to their default value ; in such case it should assume that these attributes are not used.
- a target/an interconnect may return a response status different from TLM_INCOMPLETE_RESPONSE and TLM_OK_RESPONSE to provide complimentary information about the reason why the debug request did not succeed. In particular, an interconnect may set the response status to TLM_ADDRESS_ERROR_RESPONSE to indicate that no target was present at the given address of the DMI request.

Regards,

Jerome

From: Bart Vanthournout [mailto:Bart.Vanthournout@synopsys.com]
Sent: Wednesday, December 01, 2010 7:46 PM
To: Jerome CORNET; Bishnupriya Bhattacharya; john.aynsley@doulos.com; P1666 Technical WG
Subject: RE: Minor TLM enhancements/fixes

Jerome,

OK, I need to get back to the basics here, I didn't find back the exact change you are proposing so I might have misread things: What are you suggesting to change to 12.2.4.k) and 12.3.4.o) ?
Right now these rules use words like 'is not obliged to use' and 'can be ignored' when talking about the use of attributes for DMI and Debug, I was under the impression that you wanted to change that to 'must use', and I don't want that for backward compatibility reasons.

Bart

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