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
-----owner-systemc-p1666-technical@eda.org wrote: -----
To: systemc-p1666-technical@eda.org
From: john.aynsley@doulos.com
Sent by: owner-systemc-p1666-technical@eda.org
Date: 12/07/2010 02:58AM
Subject: RE: Minor TLM enhancements/fixes
Stuart, Bishnupriya, All,
In my opinion, the use of byte enables and streaming width with Debug and the use of the response status with Debug and DMI would both be good features to add to the base protocol. But please be clear that this is not what Jerome is proposing. Because of the need for near-backward compatibility, an interconnect or target is free to ignore byte enables and streaming width for Debug without giving any indication that is has done so, an initiator is similarly free to ignore the response status, and in both cases, however unlikely, there can be no guarantee that the attributes were not set by accident. This is contrary to the spirit of the base protocol as it stands. TLM-2.0 already offers a more robust solution - ignorable extensions.
That said, if we were to get consensus to make these changes, what would we add to the LRM? Jerome's re-wording (with apologies to Jerome - his hands are tied by the need for backward compatibility) effectively says "you can bend the rules of the base protocol, but if you are using any components you did not write yourself, you cannot guarantee the results." To my mind, that's not a good thing to add to the LRM.
Votes please: "yes", add these changes, or "no", don't.
John A
-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: Stuart Swan <stuart@cadence.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Jerome CORNET <jerome.cornet@st.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 12/06/2010 05:59PM
Cc: "Bart.Vanthournout@synopsys.com" <Bart.Vanthournout@synopsys.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: Minor TLM enhancements/fixes
I think Stuart has put it very well. I strongly agree with him.
-Bishnupriya
From: Stuart Swan
Sent: Monday, December 06, 2010 10:34 PM
To: john.aynsley@doulos.com; Jerome CORNET
Cc: Bart.Vanthournout@synopsys.com; Bishnupriya Bhattacharya; P1666 Technical WG
Subject: RE: Minor TLM enhancements/fixes
John, All-
I think you should put these items up for a vote.
I vote yes on them. I’m in agreement with you that these enhancements are “a good thing”, and I also agree that the argument on both sides are not black and white.
Where I differ is in yours and Bart’s rather extreme concerns about backward compatibility. It seems to me that these concerns are overblown, and that even if such legacy models existed that exhibited the backward compatibility issues, we’d all agree that they were poorly written.
Also, I think we are making a mistake in viewing the OSCI TLM2.0 LRM as “perfect”. In reality there are remaining HUGE open issues (e.g. endianness handling) with the OSCI TLM 2.0 LRM and there are all kinds of models being developed out there that claim TLM2.0 compliance when in fact they are not.
I think the kind of reasonable (and very minor) evolution of the standard that Jerome is proposing makes sense, and I imagine there will be more of it in the future.
Thanks
Stuart
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Monday, December 06, 2010 7:42 AM
To: Jerome CORNET
Cc: Bart.Vanthournout@synopsys.com; Bishnupriya Bhattacharya; john.aynsley@doulos.com; P1666 Technical WG
Subject: RE: Minor TLM enhancements/fixes
Jerome, All,
Well said.
The TLM-2.0 LRM says that for DMI and Debug,
1) a BP initiator is not obliged to initialize any of the attributes under discussion, and that
2) any BP component is free to totally ignore the values of those attributes
So as things stand, you can have your BP components use the byte enables and response status with DMI and debug so long as you accept that every component is free to totally ignore these attributes. This is the basis for BP extensions in TLM-2.0 as things stand.
I think the enhancements you want to add would be a good thing, and I agree the argument is not black-and-white, but personally I have to vote "no" at this point.
John A
-----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/06/2010 10:34AM
Cc: "Bart.Vanthournout@synopsys.com" <Bart.Vanthournout@synopsys.com>, "bpriya@cadence.com" <bpriya@cadence.com>, P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: 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 not8 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 purpose8. 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 &compliant8 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-proof8 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:
on one hand the issue of enhancing error reasons for DMI and Debug
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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Dec 6 21:34:16 2010
This archive was generated by hypermail 2.1.8 : Mon Dec 06 2010 - 21:34:19 PST