RE: Minor TLM enhancements/fixes

Bart,

comments below.

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

>>Regarding 12.2.4.k): clearly there is no additional backward compatibility introduced, since there is no change to the standard. But that >>means I do not see the value of the clarification, I'm worried it might cause confusion and that users may start to think something should or >>will be done with the response attribute and incorrectly expect that this is the advised way to use this API...

You are right, and again I apologize for my probably inadequate english wording. This is a matter of "should/could/shall" that John is able to resolve far better than me. I think however you got the idea: this is backward compatible, and this defines clearly optional ways of giving an information about the reason why a transaction performed on these DMI and Debug interfaces actually failed. This optional ways are left in a completely grey area of the standard prior to this modification, hence the added value.

>>Regarding 12.3.4.o): here there is a change to the standard; there is an expectation that if an initiator uses byte_enables that it can rely on >>the response_status. This is an issue for initiators that reuse a payload from a previous transport call, in this case streaming_width or >>byte_enables might have been set, causing an incompatibility with the extended rule. Rule 12.3.4.p) states that reuse of payloads is >>allowed, this would no longer be the case (or at least it would have different implications than today).
>>I would not want to make this change, in this case because of the potential backward compatibility issues.

Indeed, if an initiator uses the extended rule, it will need to rely on the response status. But the only value that it can rely upon is TLM_OK_RESPONSE. All other values, typically returned by targets not aware of that rule (as current TLM-2 models are) will be considered as "the transaction with the use of extended rule has not been understood". Hence backward compatibility.

Now, you are envisaging the particular situation where a transaction with byte enable/streaming width set to a non-default value would be reused from a previous transport call to be sent through the debug interface. If I understand well, in this case, you would expect the old byte enable/streaming width to be ignored by the target. I don't clearly understand the benefits of not reinitializing these attributes to their default value in the initiator before sending the transaction (simulation speed??) but I can point to you many disadvantages and definitely agree with Stuart that this is bad practice:

- You will possibly have in the GP a byte enable pointer resolving to an area of memory that is no longer valid at the moment of the call. Hardly a good practice; consider that that byte enable pointer could be used by say, a buggy target. You will end losing more and more time debugging the buggy target.

- Current 12.3.4.o section says "the target and any interconnect component may ignore all other attributes". Correct my reading of english, but "may" does not imply that all targets and interconnect components "will" indeed ignore all other attributes. A well written TLM-2 initiator model would better set these attributes to a neutral value (such as the default value)...

However, this is not only a matter of bad practice. The initiator you describe is just not TLM-2 compliant:
rule 15.7.a clearly states that "it is the responsibility of the initiator to set the value of every generic payload attribute [...] prior to passing the transaction object through an interface method call."
Please note that section 15 is the section covering the generic payload (independently of the interface method call used, as the wording above implies). In addition the rule talks about *every* generic payload attribute regardless of their ignorability.

This is what makes me confident that the backward compatibility situation you pointed to is not even theoretical, it is just not compliant with the actual standard.

Best regards,

Jerome

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