Re: [sv-ec] Re: [sv-bc] potential command line option

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

Steven Sharp wrote:

>>I don't have a problem with either of the proposed switches
>>being suggested.
>>    
>>
>
>Neil Korpusik did some investigation and found a variety of tools
>that came uncomfortably close to the proposed switches for configuration
>type files.  He suggested putting a 'v' in the option, for 'Verilog',
>which I did in the proposal.
>
>
>  
>
>>Making this change will introduce a double incompatibility issue for
>>vendors that did provide support for 1364-2001 configurations in
>>Verilog source in that such vendors will end up supporting both
>>1364-2001 with the keyword restrictions and 1364-2005 without.  Between
>>this and the customer design changes necessary for such a change,
>>we do not believe that removing source support is a good solution.
>>    
>>
>
>It is not clear that this would be a change to what is specified in
>1364-2001.  The text doesn't state where configs can appear, and the
>syntax boxes and BNF clearly specify that they cannot appear in Verilog
>source files.  This proposal could be viewed as an official interpretation
>with a corresponding clarification in the LRM.  There has been no prior
>request for interpretation that would conflict with this.  Supporting
>both 1364-2001 and 1364-2005 would not require different behavior.
>
>Note that specifying that configs _can_ appear in Verilog source
>files would also be a change to the LRM, and would also create
>backwards compatibility issues.  It is reasonable to compare the
>relative problems created by each.
>
>Not allowing configs in source files could create problems for any
>customers relying on such functionality in any existing tools.  This
>problem would be restricted to users of those particular tools.  It
>would be further restricted to users who were using Verilog configs.
>It would only involve relatively new Verilog code, not older legacy
>code.  It would be restricted to users who put configs in the same
>files as Verilog source.  Experience with VHDL configurations tends
>to indicate that users don't do that.  All of this reduces the users
>who might be impacted to a tiny fraction of Verilog users.
>
>I would be interested in hearing from any users who are in this
>situation and feel that this is a significant problem.  If a vendor
>claims that this is a significant problem for their customers, I
>would expect that they could find a few who would tell us so.  I have
>asked this before, and have yet to hear from any.
>
>Allowing configs in source files could create problems for any users
>using any tools.  It could cause problems whether they were using
>configs or not.  It could cause problems for legacy Verilog code in
>addition to newer code.  Based on tests with our customer design suite,
>around 15% of Verilog designs won't compile with the config keywords
>reserved.  It seems clear that this would impact far more users.
>
>Steven Sharp
>sharp@cadence.com
>
>  
>