RE: Minor TLM enhancements/fixes

Jerome,

Sorry for the poor choice of words but with "weird" I mean that from your description it is not clear what use case requires the use of these attributes, I still read it as interfacing to non-compliant models.
I don't think there is a need to require the use of the respons_status in each and every DMI call because the intended use is that you first do a regular access and on the bases of the DMI_hint try a DMI access later, so the response status doesn't matter for DMI right?

For the use of byte-enables for debug: this was discussed at length in the TLM WG and we decided against it to keep the debug API's simple (I don't know of a debugger that doesn't read full words), my biggest worry with this one is that this leads to a much bigger backward compatibility issue if we require all components to support byte-enables for debug. I'm clearly against that (we have many 10's of manyears of effort in creating TLM2 compliant components which would all need to be upgraded...)

In my view the issue you describe is when one or the other component is not compliant to the standard (i.e. needs byte enables to support debug or DMI) and you try to interface to it.
Or did I read too quickly and misunderstood your intent?

Bart

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

Bart, All,

comments below.

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

>> Regarding the request to change 12.2.4k and 12.3.4.o (not obliged to set the response status on DMI or Debug or to react on byte_enables etc):
>> The goal of the restrictions there was to keep DMI and Debug as simple as possible and focus on their originally intended use case. Opening >> these API's up will cause all kinds of weird uses of these API's to bypass the TLM interfaces for other purposes.

Can you be more specific here? What kind of weird uses? To me "bypassing the TLM interfaces" means not using them...

The more possibilities that would be "opened" up by the proposal are well-known and corresponds to the capabilities
of the generic payload. No more, no less.

>>The rules do not enforce setting these attributes, but they also do not forbid. So they can be used, even in a GP context, and it is possible to >>enforce this through custom protocols etc. Which is the preferred way of addressing this.

As I replied to John's answers, I agree that people are indeed free to do what they want with custom protocols, however
this does not solve the interoperability problem. Hence the proposal.

It would really be nonsensical to create an extension and standardize it later to address this specific issue...

>>I don't think there is anyone that is going to retry a debug or DMI transaction by looking at the response status, so the benefit does not weigh up to the backward compatibility nightmare we would create when enforcing this.

Could you be more specific on the said nightmare?

I explained very clearly that getting an error response status clearly ease debugging in situations that are very similar to the GP+transport/nb_transport. How to you distinguish between a DMI request that returns "no DMI" and one that has failed
because of an addressing error?
I already explained why effects on backward compatibility are very limited. Do you have specific cases in mind?
This would really help progressing on this issue...

I have difficulties understanding your motives for rejecting this proposal... hence I cannot really discuss and help address your possible
concerns on this topic.

Best regards,

Jerome

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