From: Jayaram Bhasker (jbhasker@cadence.com)
Date: Fri May 10 2002 - 09:18:58 PDT
Precedence: bulk
Adam:
Thanks for your feedback. On reading the LRM further, I came to the following
conclusions:
1. library source text is indeed separate from module and primitive source text (2nd
para in 13.2.2 and from BNF).
For example, I cannot have a library declaration and a module declaration in the same
file.
2. The library source text can only contain library declarations, include statements
and config declarations and Verilog comments (2nd para in 13.2.2).
3. LRM is silent on compiler directives appearing in library source text. Question is
is library source text considered Verilog HDL source or not? I think it is - first
para, annex A. If so, then we need to make an explicit statement regarding
compiler directives in library source text.
4. Sec 13.2.1 says that all library source text files shall be read first by the parser.
So if I have:
> myparser a.v b.v c.v d.v e.v
and b.v and e.v contain library source text, should myparser read b.v and e.v first
before reading a.v, etc? Looks like the parser has a tough job as it has to peek
inside to see what kind of file it is.
or was it the intent to have:
> myparser -liboption "b.v e.v" a.v c.v d.v
?
5. If the parse has to read the library source text first (13.2.1),
there is not much the parser
can do when configurations are read as the verilog modules have not yet been parsed.
This sort of contradicts 13.4.3 where it says that "all cells in the design shall
be precompiled prior to binding the design". Looks like a chicken and egg issue!
- bhasker
-----Original Message-----
From: Dennis Marsa [mailto:drm@xilinx.com]
Sent: Thursday, May 09, 2002 1:39 PM
To: Adam Krolnik
Cc: btf@boyd.com
Subject: Re: Bug in file_path_spec: libraries
Precedence: bulk
Adam Krolnik wrote:
>
> Precedence: bulk
>
> Hi Jayaram;
>
> >This indeed is getting interesting. So now
> >there are two forms of include's (different syntax,
> >identical meaning?):
>
> >`include "a/b/c.d" -- a compiler directive
> >include /a/b/c.d; -- include in a configuration
>
> >From 13.2.2, it appears that the semantic meaning of the
> >config-include is
> >same as that of the include compiler directive. If so, what
> >was the reason for the config-include?
>
> There is a difference in the semantic meaning of the configuration
> include. The difference lies in the fact that a configuration
> included still processes relative file references from the
> directory of the included configuration file.
Is the term "configuration include" appropriate? Wouldn't
"library map include" be a better term?
I say this because the new kind of include is defined by
a BNF rule section A.1.1 titled "Library source text".
Configuration syntax is defined in section A.1.2 titled
"Configuration source text" and does not reference the new
BNF rule for library includes, so presumably one would have
to use the orignal `include directive in order to do includes
within a configuration?
> I guess as a methodology note that `include is not recommended
> in library definition files. They should be separate from any
> verilog code so that one can maintain them independently of
> the verilog source. It also makes it easier to write tools to
> parse just them for source code locations.
I don't see this made explicit anywhere in the standard, but
was it intended to allow library map definitions and/or
configurations to appear in the same source file as module
definitions?
Put another way, are the syntax for library maps (A.1.1) and
configurations (A.1.2) considered additions to the overall
verilog language, or separate companion languages?
What seems to make the most sense to me is that library map
syntax is really a separate companion language, but that
configuration syntax is an addition to the overall verilog
language.
Comments?
Dennis Marsa
Xilinx, Inc.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:37 PDT
and
sponsored by Boyd Technology, Inc.