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.