[sv-bc] Re: potential command line option

Rnady,

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.

Shalom


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
> primitives.
> 
> 4.	Because configurations share the same parser and scanner as the
> rest of the Verilog source, they also inherit and can share preprocessor
> `define's.
> 
> 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.
> 
> Regards,
>   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