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.Received on Mon Nov 15 07:49:43 2010
This archive was generated by hypermail 2.1.8 : Mon Nov 15 2010 - 07:49:44 PST