Re: [sv-ec] 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