Subject: Re: [sv-ec] System Include Proposal - Version 2
From: Neil Korpusik (Neil.Korpusik@eng.sun.com)
Date: Thu Mar 13 2003 - 09:43:31 PST
Thanks Jay,
This second proposal addresses all of my concerns (including one
that I didn't get a chance to send email out on yet...).
Neil
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> content-class: urn:content-classes:message
> MIME-Version: 1.0
> Subject: [sv-ec] System Include Proposal - Version 2
> Date: Thu, 13 Mar 2003 09:33:49 -0500
> X-MS-Has-Attach:
> X-MS-TNEF-Correlator:
> Thread-Topic: System Include Proposal - Version 2
> Thread-Index: AcLpbY5LIHodKDQIQIqs3/d8bYHjGA==
> From: "Jay Lawrence" <lawrence@cadence.com>
> To: "sv-ec" <sv-ec@eda.org>
> X-Received: By mailgate.Cadence.COM as GAA08991 at Thu Mar 13 06:33:50 2003
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id
h2DEXrsD011683
>
>
> Here is a second shot at the system include proposal.
>
> This proposal extends the Verilog 1364 include mechanism to define an
> installation specific include mechanism. This is provided so that the
> language standard can use the include mechanism to refer to standard
> extensions to the language that are available in source form. Typically
> a vendor will provide a tool installation to the customer, embedded
> within this tool installation or at some other vendor known location,
> the standard language extensions should be found.
>
> Various comments have been made over the last few days which have caused
> me to actually simplify the proposal even more to make it clear and
> unambiguous. A paraphrase of each of the comments and my response is
> given here. Hopefully this will accellerate discussion of the proposal
> in Friday's meeting so we can get it behind us. Following these
> comments a new version of the proposal is given.
>
> Jay
>
> -----------------------------
> Comment 1: (in sv-ec meeting)
> -----------------------------
>
> - Don't change the behavior of "file"
>
> I agree, the searching of the system include after the -I lines might
> cause backward compatibility problems and is just not worth changing.
> The proposal now states that "file" is unchanged.
>
> -------------------------
> Comment 2: Stephen Willis
> -------------------------
>
> - I believe if you are introducing a C-like feature, you should
> follow C-like practice as well. Maybe even extract the description
> from the C standard?
>
> So far I've found 3 different definitions of how this works with GNU,
> Visual Studio, and SunWSPro. If there was one consistent definition I
> would agree with this comment whole heartedly, but alas there is not
> one. I've simplified the proposal so that <> only searches the system
> include area.
>
> -------------------------------
> Comment 3: Kevin Cameron
> -------------------------------
>
> - Use [] instead of <>. This was suggested to separate
> OS-specific includes from tool specific includes.
>
> This proposal only deals with code defined by the language standard. If
> there are OS specific extensions to the language standard in the future
> then they will also live here. Kevin continues to want to share 'C' and
> 'SV' headers after running them through a pre-processor. I would
> suggest you can do this by just defining your own -I directory that you
> place the pre-processed headers in and reference them with the existing
> "file" syntax like any other source in your design.
>
> -----------------------------------------------
> Comment 4: on sv-ec mailing list (I forget who)
> -----------------------------------------------
>
> - How do I provide my own copy of these?
>
> We may want to address this with further wording in the Annex'es for
> each element, but it is not pertinent to the semantics of <>. One
> important point is that for Lists the body of the methods is not
> provided. This leaves a vendor the ability to provide an optimized
> implementation that could not be written in SystemVerilog, providing
> your own bodies would either cause them to be ignored or cause severe
> performance penalties. User's always try to do this in VHDL and it is
> always a disaster (providing there own version of STD packages). To use
> your own version a different name in a diffent directory is the safest
> course (It may inherit the standard class).
>
> ------------------------
> Comment 5: Neil Korpusik
> ------------------------
>
> - Why provide relative paths under <>?
>
> This is just a more generic extension. Just like 'C' allows
>
> #include <sys/signal.h>
>
> As the amount of code grows under <> it may make sense to divide it up
> by subdirectories in the standard itself.
>
> `include <types/list.vh>
> `include <types/semaphore.vh>
> `include <math/trig.vh>
>
> ----------------------
> Comment 6: Brad Pierce
> ----------------------
>
> - The syntax is incomplete because it doesn't handle macros
>
> No Verilog syntax explicitly calls out macros. They can be used
> anywhere, anytime.
>
> --------------------
> Proposal - Version 2
> --------------------
>
> The syntax of the include compiler directive will be as follows:
>
> include_compiler_directive ::=
> `include "filename"
> | `include <filename>
>
> When the filename is an absolute path, only that filename is included
> and only the double quote form of the `include can be used.
>
> When the double quote ("filename") version is used, the behavior of
> `include is unchanged from Verilog-1364.
>
> When the angle bracket ("<>") notation is used, then only the vendor
> defined location containing files defined by the language standard is
> searched. Relative pathnames given inside the <> are interpreted
> relative to the vendor-defined location in all cases.
>
>
>
> ===================================
> Jay Lawrence
> Architect - Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 09:45:20 PST