From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Fri May 03 2002 - 15:43:19 PDT
Precedence: bulk
At 03:29 PM 5/3/02 -0600, Dennis wrote:
>Precedence: bulk
>
>Adam Krolnik wrote:
> >
> > Precedence: bulk
> >
> > Hello Jayaram;
> >
> > The specifications do not include double quotes to specify
> > filenames. Since the library mapping file deals with mostly
> > filenames, we saw no need to require quoted filenames.
> >
> > Example 13.7.3 incorrectly specifies quotes when should not
> > be specified.
True. We voted to remove the "" as unnecessary. This is a typo. The smart
quotes are especially annoying in this example.
>Yet, the include_statement production shown in the
>Syntax 13-2 box on page 201 requires an include file
>name be delimited with <>!
This is a typo. No <> required (or valid).
>Anyway, wouldn't some sort of delimiter be necessary for
>certain kinds of filenames in library statements?
>
>The syntax for the library statement specifies using ',' to
>separate file paths.
>
>But, ',' is a valid character that can be used in a filename.
>So, consider:
>
> library mylib foo.v,bar.v
>
>Does the above map 2 files, or 1 file to mylib?
This should be two files. We did not think about "," being a legal
character in a file path name.
>Also, blanks can be used in filenames as well. Without
>using a wildcard, wouldn't one need some sort of delimiter
>in order to specify a file containing blanks?
>
> library mylib < foo.v>
We did not consider filenames with blanks.
>If not required, perhaps <> delimiters should be an option in
>library file path specifications?
We can bring this up when the VSG reconvenes but I would vote against it.
Perhaps we need to make "" optional, but required for the odd-named file
formats (any file with blanks, commas, what else?)
>Dennis Marsa
>Xilinx, Inc.
Side note. Section 13 is new to Verilog-2001. We did our best to eliminate
bugs but obviously were unsuccessful. Had this section been perfect on the
first publication, there would have been no living with us (the BTF) ;-)
For all of its bugs, the IEEE Verilog Standards have come a long way.
Take a peak at an early Verilog book such as a first-edition Thomas-Moorby
book. Look at the BNF (appendix F). That is basically where we started with
the Verilog-1995 Standard.
Thomas-Moorby F.3 PRIMITIVE INSTANCES
<gate_instantiation>
::= < GATETYPE> <drive_strength>? <delay>? <gate_instance>
<,<gate_instance>>* ;
<GATETYPE> is one of the following keywords (all gate and switch types
keywords listed)
...
<gate_instance>
::= <name_of_gate_instance>? ( <terminal> <,<terminal>>* )
This syntax permitted and-gates with a turn-off delay, tran switches with a
variable number of ports, switch primitives with drive strengths and a host
of other illegal gate primitive instantiations.
For the Verilog-1995 Standard, I put together hundreds of gate
instantiations and used Verilog-XL to figure out what the gate and switch
BNF should really be.
The Verilog-1995 BNF was light years ahead of all previous Verilog BNF
descriptions, but it was still buggy.
For the Verilog-2001 Standard, I took over the BNF and turned all of the
keywords and tokens into red-bold text. I also created a web version of the
BNF and I think it was Adam who created a Perl script to link the BNF
productions together. Between red-bold keywords and hyperlinked text, we
discovered and corrected a whole host of additional problems with the BNF.
I just wish the IEEE had put the red-hyperlinked version of the BNF in the
PDF release of the Verilog-2001 Standard. I think that would have been
exceptionally useful to end-users. One of these days, the IEEE is going to
enter the 21st century (in about 100 years ;-)
With each new Verilog Standard we will continue to refine and fix the BNF,
and with each new Verilog Standard that includes enhancements, we will most
likely introduce more BNF bugs. We could quit enhancing the Verilog
language but then people would think it is VHDL ;-) ;-) ;-)
We appreciate all of the reported BNF bugs and hope to fix them all. Point
is, it could be worse! (Believe me, it was!!)
Regards - Cliff
----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, Synthesis and Verification Training
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:36 PDT
and
sponsored by Boyd Technology, Inc.