RE: Minor TLM enhancements/fixes

John,

I prefer to ignore this email and advise participants to do so, as:


- it completely mixes a personal opinion and a call for a vote

- it misrepresents the proposal I did to this group

- it seems you changed your mind in a subsequent email and that you are now proposing

a new vote that [at least partially] supersedes this one.


We have the responsibility for the group to conduct debate in a proper and clear manner.
I refuse to think this is part of a strategy to miss the deadline on this feature, and call you
for a more neutral way of conducting the debate.

I put Stan in copy, as I think we have to be very careful here. I strongly hope this warning
will prove unnecessary.

Jerome


From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, December 07, 2010 3:58 AM
To: systemc-p1666-technical@eda.org
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 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:

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<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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