Subject: [sv-ec] System Include Proposal - Version 2
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Mar 13 2003 - 06:33:49 PST
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 - 06:34:38 PST