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

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Thu Apr 21 2005 - 07:04:33 PDT

  • Next message: Michael McNamara: "Re: [sv-bc] potential command line option"

    Hi, Steve -

    Long-time no-hear!

    At 04:59 AM 4/21/2005, Pragmatic C Software wrote:
    > I thought we had already agreed to this. Cver follows XL and does
    >not allow configs in source files.

    XL does not allow configs, period. XL will not support them. XL will not
    even support Verilog-2001, except standard random numbers (based originally
    on XL) and signed arithmetic.

    >Allowing configs in source files
    >(made even worse if `defines are allowed) is not algorithmically correct
    >in the sense that circularities occur.

    How so? I sent example PDF slides of how this works yesterday and it seems
    good by me.

    `defines can be problematic unless they are put in the first file compiled,
    and that has nothing to do with configs. I give the guideline to use
    parameters 1st, `defines 2nd. Prove to yourself that you really need
    `defines at a global level. I still find engineers adding `defines to
    define FSM states. The Reuse Methodology Manual, 2nd edition says to use
    `defines for FSM state definitions (*bad*) and then shows all examples
    using parameters (*good*).

    >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.

    I disagree. I think Mentor got it right (except I would like to see them
    read a local lib.map file without any required command line switch)

    >All
    >three large vendors have such features.

    As of last year, this was still broken on every simulator I tried. We need
    to clarify so vendors can get it right and the same. I think Mentor has
    this one right, per intent.

    >/Steve

    Regards - Cliff

    >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

    ----------------------------------------------------
    Cliff Cummings - Sunburst Design, Inc.
    14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
    Phone: 503-641-8446 / FAX: 503-641-8486
    cliffc@sunburst-design.com / www.sunburst-design.com
    Expert Verilog, SystemVerilog, Synthesis and Verification Training

    This archive was generated by hypermail 2.1.4 : Thu Apr 21 2005 - 06:45:41 PDT and
    sponsored by Boyd Technology, Inc.