RE: Include files names/paths in the LRM

John,

comments below.

From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, November 09, 2010 2:57 PM
To: systemc-p1666-technical@eda.org
Subject: Include files names/paths in the LRM

>The OSCI TLM-2.0 LRM includes several sections (10.2, 11.8, 11.8.1) that refer explicitly to the directory structure of the OSCI TLM-2.0 kit. We will want to omit most of these dependencies from the IEEE standard, right?

Agreed.

>However, the OSCI LRM requires applications to #include the header files of any utilities from the tlm_utils directory, which raises the following questions:
>- Does the directory tlm_utils need to be documented in the LRM?

In my opinion, no. These files are not strictly part of the TLM standard, although they are of course part of
the TLM kit distributed by OSCI (see below).

>- Do the names of the utility source files need to be documented?

Following first point, no.

>- If not, how can applications that use TLM-2.0 utilities be made portable across implementations?

That is the good question indeed. I think there is not perfect solution to this.

Including the files (answering yes to the first question) means:
  - additional documentation work for IEEE,
  - additional burden for implementers of SystemC (the parts in tlm_utils are (unlike the rest of the standard) sensitive to 64 bits
issues, external library dependencies (as was demonstrated with the boost problem on the OSCI TLM 2.0 release), etc.
for which interoperability benefit? None, as the tlm_utils classes are not necessary at all to allow interoperability (not part of the standard).

In addition, I should mention that despite the very good work done by volunteers of the TLM WG (including myself):

* the various sockets types is both a mess for the user to choose from and also to document (see TLM manual by John)

* the endianness conversion functions hardly support all of the situations encountered with TLM-2 transactions (which opens

all sort of questions when documenting).

Not including the files means basically that the user cannot rely on the utils being present in the TLM install. If they choose
to use them, they'll have to bundle them with their model. This sounds potentially cumbersome, but on the other hand,
the users will anyway need to add missing functionality to them so and probably distribute their own derived class.

So, in my opinion this is worth the inconvenience to avoid the tlm_utils for IEEE. Obviously they remain fully essential
(as example purpose) say, in the OSCI TLM distribution.

I look forward other members opinions on this topic...

>In the TLM-2.0.1 kit, the header file is named "tlm.h". This name does not follow the convention used in SystemC, where
>"systemc.h" is the old-style header that dumps all names into the global namespace
>"systemc" is the new-style header where all names are in sc_core or sc_dt

>Since the TLM-2.0 header is a new-style header, by rights it should have been named "tlm", be we need to retain the name "tlm.h" for backward compatibility. Any suggestions?

To me the TLM-2.0 header (wrongly named, since it also includes TLM-1) is not especially new (dates back to TLM-1) this could explain this tlm.h old style.
 I would favor the same solution as for systemc: <tlm> new-style include without using namespace directives; <tlm.h> old style similar to <systemc.h>.

Cheers,

Jerome

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