RE: Include files names/paths in the LRM

I agree with Bart. Is everybody okay with this?

Thanks,

John A

From:
Bart Vanthournout <Bart.Vanthournout@synopsys.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, David C Black
<dcblack@xtreme-eda.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>, "jerome.cornet@st.com"
<jerome.cornet@st.com>, "Bart.Vanthournout@synopsys.COM"
<Bart.Vanthournout@synopsys.COM>, "Wieman, Trevor"
<trevor.wieman@intel.com>, "Marcelo.Montoreano@synopsys.COM"
<Marcelo.Montoreano@synopsys.COM>, "Stuart Swan" <stuart@cadence.com>
Date:
12/11/2010 13:39
Subject:
RE: Include files names/paths in the LRM

John,

it would be best to include the filenames and directory names, too much
code already depends on it and as you mention we did want to have the
utilities explicitly mentioned in the include path.

Bart

________________________________
From: john.aynsley@doulos.com [john.aynsley@doulos.com]
Sent: Wednesday, November 10, 2010 12:54 PM
To: David C Black; systemc-p1666-technical@eda.org; jerome.cornet@st.com;
Bart.Vanthournout@synopsys.COM; Wieman, Trevor;
Marcelo.Montoreano@synopsys.COM; Stuart Swan
Subject: Re: Include files names/paths in the LRM

All,

Okay, we agree no TLM-2.0 directory structure in the LRM.

There was some confusion as to whether the TLM-2.0 utilities are part of
the standard. Absolutely they are! (Nobody has proposed we remove them.) I
was only querying whether the filenames should be standardized in the LRM,
including the "tlm_utils/" prefix.

Personally I see no problem with fixing the directory prefix "tlm_utils/"
in the 1666 standard. This is not an onerous burden on the implementer.
Obviously, it just means that the standard utilities have to go into a
sub-directory with a particular name.

In the TLM-WG we decided to require an explicit #include for each utility
just to avoid having them all included and to emphasize which utilities
were being used. Directives such as

#include "tlm_utils/simple_initiator_socket.h"

are now widespread in the legacy code base, so think it would be desirable
to standardize these filenames in 1666. Implementers would be crazy to put
the standard utilities anywhere else, since this would break existing
code. This would not stop users or implementers adding their own utilities
using different filenames and/or pathnames, which was always the
intention.

What do people think (especially the TLM-WG folk)?

John A

From: David C Black <dcblack@xtreme-eda.com>
To: john.aynsley@doulos.com
Date: 10/11/2010 00:18
Subject: Re: Include files names/paths in the LRM

________________________________

Ah. My reading suggested you were asking about documenting the utilities
that are located under the directory. Sorry about the misunderstanding on
my part. I'm not sure, but I think others may feel it is not needed.

As to the directory name/structure, I don't think it's important as long
as the users can locate the proper include files.

On Nov 9, 2010, at 2:33 PM, john.aynsley@doulos.com<
mailto:john.aynsley@doulos.com> wrote:

David,

Just to be clear, I was not suggesting for a moment that we do not
standardize the TLM-2.0 utilities, but merely asking whether the directory
name itself should be part of the standard.

John A

-----David C Black <dcblack@xtreme-eda.com<mailto:dcblack@xtreme-eda.com>>
wrote: -----
To: john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>
From: David C Black <dcblack@xtreme-eda.com<mailto:dcblack@xtreme-eda.com
>>
Date: 11/09/2010 05:08PM
Subject: Re: Include files names/paths in the LRM

On Nov 9, 2010, at 7:56 AM, john.aynsley@doulos.com<
mailto:john.aynsley@doulos.com> wrote:

Nobody responded to this one first-time-around. Comments please!

Oops...

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?

Yes, omit directory structure.

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?

Good question. I find several of the utilities appear to be extremely
useful even if not essential. Yes, everyone can work around them and
reinvent or copy from the kit, but that doesn't make a lot of sense to me.
Why wouldn't we include material that almost everyone uses? Who doesn't
use some aspect of tlm_utils? Perhaps the utilities need more work in the
main standards committee.

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

No

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

It seems more work might be needed.

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?

I would be in favor of renaming tlm.h to tlm in the same vein as systemc
was.

Thanks,

John A

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com<http://www.xtreme-eda.com/>
(Consulting, Services & Training for all your ESL, verification and DFT 
needs)
Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609
------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com<http://www.xtreme-eda.com/>
(Consulting, Services & Training for all your ESL, verification and DFT 
needs)
Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.