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 > > >Received on Wed Apr 20 10:33:40 2005
This archive was generated by hypermail 2.1.8 : Wed Apr 20 2005 - 10:35:18 PDT