RE: Minor TLM enhancements/fixes

Jerome,

OK, I need to get back to the basics here, I didn't find back the exact change you are proposing so I might have misread things: What are you suggesting to change to 12.2.4.k) and 12.3.4.o) ?
Right now these rules use words like 'is not obliged to use' and 'can be ignored' when talking about the use of attributes for DMI and Debug, I was under the impression that you wanted to change that to 'must use', and I don't want that for backward compatibility reasons.

Bart

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

Hi Bart,

thanks for your answer. Some responses below.

From: Bart Vanthournout [mailto:Bart.Vanthournout@synopsys.com]
Sent: Wednesday, December 01, 2010 5:50 PM
To: Jerome CORNET; Bart Vanthournout; Bishnupriya Bhattacharya; john.aynsley@doulos.com; P1666 Technical WG
Subject: 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 fully understand that part: obviously if someone create a model that does not comply with the current
debug/DMI rule, he will indeed have created a model that is "non-compliant" (base-protocol non compliant, to be more precise).
We are building things natively on top of TLM-2. Our problem is that TLM-2 overly restrict something that prevents us
from implementing very common use cases directly in TLM-2 (and that we have been using since many times...).
No problem: we create extensions (we don't even have to change the traits class). Except that is non-sensical from
the interoperability point-of-view and that the stuff addressedis fully within the scope of the base protocol, and
touches attributes that are standard in the GP. The idea is that everyone should benefit from it, not only the people
that are aware of a particular extension.

>>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?

Right in theory, the DMI Hint is obtained through the transport interface, and thus you can benefit from the response status
on this one. But this a rather poor "workaround": the DMI Hint, is -as the name implies - a hint, and it requires doing
a regular transaction to the target. There are many cases where the initiator wants a DMI access from the beginning of the simulation
(say to map part of a local memory to a remote component), and does not have any regular transaction to issue ; this has been discussed
explicitly on the TLM WG. In such cases, you need to use the DMI interface calls directly without prior calls to the transport interface.

>>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),

What was discussed at length was the fact that a some point in time in the standard's definition, the data structure transported over the debug interface was not the generic payload, but a poorly redefinition of some of its fields. It has been decided to move to the GP to precisely
address the many use cases that don't fall in the simple "debugger" use-case you are talking about (and that was also "fine" with
the simple debugger use case), as multiple participants pointed out that this was not the only valid use-case.
We have now is a fully-capable standard, except that some old rules from the debug payload remains (no one is perfect).

>> 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...)

I definitely agree with you: requiring targets to support byte enable, streaming width et al. is not ok.
Fortunately, that is not what I propose: I propose to just leave existing IPs as they are. You will agree that given
the standard, it is not quite uncommon to check the transaction minimally before processing it (say check
that data pointer is ok, and so forth). I just propose to rely on these *existing* checks and allow forgotten use
cases through a slight relaxing of the rules.

I have seen far more complex issues and backward compatibility stumbling blocks in the discussions over the
pure SystemC part of this standard than anything here. TLM-2 is a good standard, but it is not perfect (as SystemC!),
 and it needs to evolve at a minimum and fully take into account the needs of its users...

Jerome

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