RE: Minor TLM enhancements/fixes

John,

thanks for this nice summary. I think we are converging.

See additional comments below.

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Sunday, December 05, 2010 7:58 PM
To: Jerome CORNET
Cc: Bart.Vanthournout@synopsys.com; bpriya@cadence.com; john.aynsley@doulos.com; P1666 Technical WG
Subject: RE: Minor TLM enhancements/fixes


>>Re. if we allow the response status to be used with DMI, the trouble is that there is no guarantee that the response status has
>>been initialized (see below), nor that other components will not use it too for their own devious purposes. An initiator can
>>check the DMI response status, but it cannot absolutely rely on the value it sees, with or without Jerome's proposal.

I think we cannot argue solely on the base of “may/may not” in the standard (and that is not what I did previously, see my latest email about initialization of payload attributes). Else we lose connection to reality...

You say: there is no guarantee that the initiator initializes the response status. Indeed I was wrong on this point, this is possible in theory (see my answer below). But in my proposal, which component will indeed use the response status to provide enhanced information about an error, if it occurs? The initiator. Which component is responsible for the initialization? The initiator. So I guess that an initiator that wants enhanced information about the reason why a target rejected a DMI request or did not copy all the bytes in a debug request will indeed initialize the response status...

Now, about the target. With your argument, a target may set the response status to any value it want for “devious purpose”. What such devious purpose? For which reason? No one knows...
The only logical devious reason for using the response status is indeed.... to clarify the reason why something wrong happened. And we are just talking about standardizing its optional use.

Finally, let’s imagine that, as you said, the target set the response status to something completely random. And that the initiator exploit it. What will happen? The otherwise unknown reason for DMI rejection or debug request fail will be unknown (case of TLM_OK_RESPONSE) or just wrong. It is worse than having no information at all in the “compliant” case? I don’t think so.

>>With debug, Jerome proposes that an initiator MAY set other attributes (i.e. byte enable and streaming width) and that the >>target SHALL set the response status to OK if it has honored them. In practice, this should be fine most of the time. BUT >>Bart's point is valid: legacy initiators may leave byte enables set by accident. Jerome quotes rule 15.7.a as saying that every >>GP attribute must be initialized. But this needs to be qualified by 15.6 l) which says the modifiability rules only apply to the >>appropriate attributes. (The LRM could be improved here)

That’s right. I was wrong on 15.7.a. But that does not predate my other arguments, as others pointed out, that this is bad practice.
As Bart said, such situation may occur when using a pool of transactions that can be sent to whatever interface (transport, debug, DMI).
I again ask why on earth would someone not initialize all the attribute (Simulation speed?). Whereas it is widely recognized at a general bad programming practice and that you and your customer will lose time when debugging issues with the transaction?


John, I disagree with your proposal that whatever the case, an extension is always required.

I think we should be more balanced in the approach we are taking. For sure, the extension allows “bullet-proof” detection
of the enhancement even in bad practice cases or hypothetical situations. But standardizing an extension has a price:

- The improvement is delayed for an unspecified time (and we do not have any process setup to discuss extensions
at this point) and therefore therer will still be an interoperability problem,

- This will need to restart discussions and take additional time that could otherwise be spent on all the TLM stuff
 that is still not yet standardized and that needs to.
- This will require customers to add dependencies for features that are closely related to the built-in attributes of the generic
payload.

I think we have reached a point where we have finished digging with the technicalities and that the consequences
of the various choices are clear for everyone.
Let us let the participants review this and do their choice...

I would vote for separating:

1) on one hand the issue of enhancing error reasons for DMI and Debug

2) on the other hand, the proposal to use extended attributes (streaming width, byte enable) with the debug interface.

Best regards,

Jerome

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