RE: Include files names/paths in the LRM

Just following myself up - sorry :-(

I realised after posting that I should have gone and read the definitions
of compliance in the current draft LRM, section 10.1, where of course it
does distinguish between a TLM 2.0 compliant implementation and a TLM 2.0
base protocol compliant model.

So I'll reduce my comment to

"I assume that these utilities are already in use, so their paths should
be specified. "

regards
Alan

-- 
Alan Fitch
Senior Consultant
Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services
From:
alan.fitch@doulos.com
To:
john.aynsley@doulos.com
Cc:
Bart Vanthournout <Bart.Vanthournout@synopsys.com>, David C Black 
<dcblack@xtreme-eda.com>, Jerome CORNET <jerome.cornet@st.com>, 
"Marcelo.Montoreano@synopsys.COM" <Marcelo.Montoreano@synopsys.com>, 
owner-systemc-p1666-technical@eda.org, Stuart Swan <stuart@cadence.com>, 
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, 
"Wieman, Trevor" <trevor.wieman@intel.com>
Date:
15/11/2010 15:50
Subject:
RE: Include files names/paths in the LRM
Sent by:
owner-systemc-p1666-technical@eda.org
I assume that these utilities are already in use, so their paths should be 
specified. 
But I suppose in theory the LRM could say that an implementation is not 
obliged to provide the utilities - but if it does, it must put them in 
certain places.Which seems strange unless you defined levels of 
compliance, e.g. 
TLM2 level 1 - no utilities; TLM2 level 2 = utilities *and* must be at the 
correct file locations. However if you did that, I guess you'd have to 
extend the macros and methods for identifying compliance and versioning 
which seems messy. 
I guess the key difference is between the interoperability layer of TLM2 
to which a model must comply (which does not require the utilities); and 
whether a tool is TLM2 compliant (which does require the utilities to be 
provided at present). 
Alan 
-- 
Alan Fitch
Senior Consultant
Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
UK
Tel:  + 44 (0)1425 471223                       Email: 
alan.fitch@doulos.com 
Fax:  +44 (0)1425 471573                        http://www.doulos.com
From: 
john.aynsley@doulos.com 
To: 
Jerome CORNET <jerome.cornet@st.com> 
Cc: 
Bart Vanthournout <Bart.Vanthournout@synopsys.com>, David C Black 
<dcblack@xtreme-eda.com>, "Marcelo.Montoreano@synopsys.COM" 
<Marcelo.Montoreano@synopsys.com>, Stuart Swan <stuart@cadence.com>, 
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, 
"Wieman, Trevor" <trevor.wieman@intel.com> 
Date: 
15/11/2010 15:18 
Subject: 
RE: Include files names/paths in the LRM 
Sent by: 
owner-systemc-p1666-technical@eda.org
Jerome, 
But SimpleBusLT.h and memory.h are merely examples. The TLM-2.0 utilities 
are widely used in application code. If you want to make a case to have 
the utilities excluded from 1666, you have to explain how to ensure 
compatibility between future SystemC/TLM-2.0 releases and the legacy 
codebase. 
Note that the draft 1666 LRM now contains definitions for TLM-2.0 
compliance, which DO oblige implementations to provide the utilities but 
DO NOT oblige applications to use the utilities. 
John A 
From: 
Jerome CORNET <jerome.cornet@st.com> 
To: 
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, Bart Vanthournout 
<Bart.Vanthournout@synopsys.com>, "systemc-p1666-technical@eda.org" 
<systemc-p1666-technical@eda.org>, "Wieman, Trevor" 
<trevor.wieman@intel.com>, Stuart Swan <stuart@cadence.com>, 
"Marcelo.Montoreano@synopsys.COM" <Marcelo.Montoreano@synopsys.COM>, David 
C Black <dcblack@xtreme-eda.com> 
Date: 
15/11/2010 15:08 
Subject: 
RE: Include files names/paths in the LRM
John, 
 
we?d lose exactly the same thing as when, say, standardizing SimpleBusLT.h 
or memory.h. 
In appearance we are gaining something, in reality we are just 
standardizing the wrong thing at the wrong level. 
 
Jerome 
 
 
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com] 
Sent: Monday, November 15, 2010 12:46 PM
To: Jerome CORNET; Bart Vanthournout; systemc-p1666-technical@eda.org; 
Wieman, Trevor; Stuart Swan; Marcelo.Montoreano@synopsys.COM; David C 
Black
Subject: RE: Include files names/paths in the LRM 
 
What do other people think? 
Jerome - what do you think we stand to lose by putting the utilities in 
1666? 
John A 
From: 
Jerome CORNET <jerome.cornet@st.com> 
To: 
"john.aynsley@doulos.com" <john.aynsley@doulos.com>, Bart Vanthournout 
<Bart.Vanthournout@synopsys.com> 
Cc: 
"Bart.Vanthournout@synopsys.COM" <Bart.Vanthournout@synopsys.COM>, David C 
Black <dcblack@xtreme-eda.com>, "Marcelo.Montoreano@synopsys.COM" 
<Marcelo.Montoreano@synopsys.COM>, Stuart Swan <stuart@cadence.com>, 
"systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, 
"Wieman, Trevor" <trevor.wieman@intel.com> 
Date: 
15/11/2010 11:32 
Subject: 
RE: Include files names/paths in the LRM
 
Not really on my side. I dug a little in the TLM Working Group email 
archive, and I can 
confirm I was not the only one to find non-obvious the sentence ?tlm_utils 
is part of the standard?. 
To me they are not, and that?s precisely why we choose to put them in a 
different include file and directory than tlm.h. 
In the TLM WG, there was a fragile consensus on: ok we include them [in 
the package], but keep them clearly separate. 
We are going beyond standardization here; it is akin standardizing 
simple_bus or whatever SystemC example under the 
pretext that someone is using it (and for sure simple_bus is used!). But 
don?t misread me: I am not against having the tlm_utils 
in the OSCI package, not at all. 
Regards, 
Jerome 
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com] 
Sent: Monday, November 15, 2010 11:33 AM
To: Bart Vanthournout
Cc: Bart.Vanthournout@synopsys.COM; David C Black; Jerome CORNET; 
Marcelo.Montoreano@synopsys.COM; Stuart Swan; 
systemc-p1666-technical@eda.org; Wieman, Trevor
Subject: 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. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.