Re: potential command line option

From: Shalom.Bresticker@freescale.com
Date: Wed Apr 20 2005 - 13:35:59 PDT

  • Next message: Mark Hartoog: "RE: [sv-ec] Re: [sv-bc] potential command line option"

    Rnady,

    Without taking any position on the proposal, I have 2 things to say:

    1. If some implementation is more flexible, I don't believe that makes it
    'illegal'. Unlike many other cases, the LRM does not state that this case
    shall be an error.

    2. On the other hand, I would not like to have the standard allow different
    interpretations. That would be an unfortunate source of incompatiblities.

    Shalom

    On Wed, 20 Apr 2005, Randy Misustin wrote:

    > 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 

    -- 
Shalom.Bresticker @freescale.com                     Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478
  
[ ]Freescale Internal Use Only      [ ]Freescale Confidential Proprietary

    This archive was generated by hypermail 2.1.4 : Wed Apr 20 2005 - 13:13:13 PDT and
    sponsored by Boyd Technology, Inc.