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

From: Pragmatic C Software (sjmeyer@pragmatic-c.com)
Date: Thu Apr 21 2005 - 04:59:24 PDT

  • Next message: Clifford E. Cummings: "Re: [sv-ec] Re: [sv-bc] potential command line option"

      I thought we had already agreed to this. Cver follows XL and does
    not allow configs in source files. Allowing configs in source files
    (made even worse if `defines are allowed) is not algorithmically correct
    in the sense that circularities occur. Since we are independents
    we can say this - I think Mentor's implementation is just another
    feature intended to lock customers into one brand of simulator. All
    three large vendors have such features.
    /Steve

    Quoting Randy Misustin (ram@model.com):
    > 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
    > >
    > >
    > > 

    -- 
Steve Meyer                             Phone: (612) 371-2023
Pragmatic C Software Corp.              email: sjmeyer@pragmatic-c.com
80 South 8th Street, Suite 900
Minneapolis, MN 55402

    This archive was generated by hypermail 2.1.4 : Thu Apr 21 2005 - 04:38:15 PDT and
    sponsored by Boyd Technology, Inc.