Date: Wed Apr 20 2005 - 13:35:59 PDT
Without taking any position on the proposal, I have 2 things to say:
1. If some implementation is more flexible, I don't believe that makes it
'illegal'. Unlike many other cases, the LRM does not state that this case
shall be an error.
2. On the other hand, I would not like to have the standard allow different
interpretations. That would be an unfortunate source of incompatiblities.
On Wed, 20 Apr 2005, Randy Misustin wrote:
> Hello Steven,
> Please allow me to make this a little less hypothetical:
> 1. Mentor's ModelSim has supported Verilog configurations since
> version 5.8, released in November of 2003. Customers have been using
> this facility, some heavily, since it's introduction
> 2. ModelSim's implementation of configurations allows the
> configurations to be freely mixed in with Verilog source.
> 3. Configurations are treated as first class design elements by our
> system. They are compiled into design libraries right beside modules and
> 4. Because configurations share the same parser and scanner as the
> rest of the Verilog source, they also inherit and can share preprocessor
> Clearly, what you propose doing will cause ModelSim's implementation of
> configurations to be illegal under the new spec.
> I've tried to go back and divine from where you derive your strong
> assertion "syntax boxes and BNF clearly specify that they cannot appear
> in Verilog source files". The best I could come up with is that
> source_text in A.1.3 and library_text in A.1.1 don't grammatically
> derive each other. Your view must therefor be that source_text cannot
> share a file with library_text, correct? I didn't find this restriction
> anywhere. In fact, the inclusion of the configuration keywords in a
> common list of keywords in Appendix B would seem to support the
> conclusion that both grammars can share a common parse.
> I also have trouble with your comment: "Allowing configs in source files
> could create problems for any users using any tools". I presume you're
> speaking to the issue of the configuration keywords (?). The keywords
> are already part of the 2001 specification. Whether you view
> configurations as allowable within a source file or not doesn't create
> the problem. The problem already exists. The keywords are part of the
> existing 1364-2001 standard. I'm quite sympathetic to your motivations
> of wanting to limit keyword explosion, but this is a bit like trying to
> close the barn door after the horses have already left, no?
> I'm not opposed to leaving things as is in the current spec, where the
> issue of whether the same parser can implement both parses is left tool
> dependant, but oppose the elimination of the configuration keywords from
> the keyword list. In the spirit of compromise, I'd be willing to
> consider separating the two lists if we could retain the keyword,
> config, in the Verilog source keywords. This would at least allow us to
> implement a messy lexical analyzer mode change based on this keyword.
> Randy Misustin
-- Shalom.Bresticker @freescale.com Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary
This archive was generated by hypermail 2.1.4
: Wed Apr 20 2005 - 13:13:13 PDT
sponsored by Boyd Technology, Inc.