Re: Config-keyword work-around - was: potential command line option

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Apr 25 2005 - 17:25:12 PDT

  • Next message: Steven Sharp: "Re: Config-keyword work-around - was: potential command line option"

    Hi, Steve -

    I better understand your dilemma as described below. More comments below.

    At 03:53 PM 4/25/2005, you wrote:

    > >There is a reasonable workaround for the config keyword issue. Users can do
    > >the following [workaround using `begin_keywords "1364-2001" omitted]
    >
    >There is a problem with this proposed solution.
    >
    >The only keywords in 1364-2001 that have caused problems in customer
    >designs are certain ones in configs. Those keywords don't really need
    >to be reserved in Verilog source if configs are not allowed in Verilog
    >source (which they technically are not).

    The "technically are not" is opinion.
    1364-2001 - Does not define any command line switches (we thought about it
    and rejected it)

    Annex A (normative) - technically they are not (this was my mistake - we
    don't force tools to implement mistakes)

    Annex B (normative) - technically config and the others are reserved words.

    Section 13 (normative) - does not prohibit configs from being in the same
    file or read in the same input stream.

    Section 13.1 (normative) -
    As evidenced by the config-endconfig syntax, the config is a design
    element, similar to a module, which exists in the Verilog namespace.

    Section 13.2.1 (normative) -
    "When parsing a source description file (or files), the parser shall first
    read the library mapping information from a pre-defined file prior to
    reading any source files. The name of this file and the mechanism for
    reading it shall be tool-specific, but all compliant tools shall provide a
    mechanism to specify one or more library mapping files to be used for a
    particular invocation of the tool. ... For the purposes of this
    discussion, assume the existence of a file named lib.map in the current
    working directory, which is automatically read by the parser prior to
    parsing any source files specified on the command line."
    This is the only reference to a possible separate library file related to
    configurations in Section 13.

    Section 13.4.1 (normative) Title: 13.4.1 Precompiling in a single-pass
    use-model
    The single-pass use-model is the traditional use-model with which most
    users are familiar. In this use-model, all of the source description files
    shall be provided to the simulator via the command line, and only these
    source descriptions can be used to bind cell instances in the current design.
    (NOTE: Section 13.4.4 tells us the legal way to bind the cells - no mention
    of required command line switches in 13.4.1)

    Section 13.4.2 (normative) Title: 13.4.2 Elaboration-time compiling in a
    single-pass use-model
    ... Once the top-level module(s) has been found, then it can be compiled
    into the library, and the tool can proceed down the hierarchy, only
    compiling the source descriptions necessary to bind the design successfully.
    (NOTE: Section 13.4.4 tells us the legal way to bind the cells - no mention
    of required command line switches in 13.4.2)

    Section 13.4.4 (normative) - In each of the three preceding strategies, the
    binding rules can either be specified via a config, or the default rules
    (from the library map file) can be used.
    (This section tells us binding happens from EITHER configs or libraries, so
    the configs were listed in the same input stream when compiled)

    Section 13.7.1 (informative note at the end of the section)
    NOTE It is recommended all compliant tools use "-L <library_name>" to
    specify this search order.
    (No -config switch recommended because none was needed to implement configs
    - you are now proposing a config switch of some variety, which is a
    reasonable proposal but one that I would prefer to omit)

    Non-normative 1364-2001 Draft 4 - config, endconfig and library were part
    of the Verilog keywords but the other config and library keywords were in
    separate keyword lists.

    There is ample evidence to show that we intended configs to be part of the
    Verilog input stream. Based on this information, to argue that configs
    could not be in the same file or read in the same input stream is a real
    stretch.

    >As a result, NC-Verilog (and
    >possibly other tools) support a dialect of 1364-2001 that does not
    >reserve those keywords. This dialect is very useful, since it can
    >compile legacy Verilog-1995 without significant keyword issues, and can
    >also compile legal Verilog-2001 designs.
    >
    >This means that there may be a significant amount of Verilog code by now
    >that uses the config keywords as identifiers, but also uses Verilog-2001
    >features. The workaround you have suggested won't work for such code.

    We are four years into the 1364-2001 Standard. Another implementation has
    agreed with my interpretation for the past two years. The fact that
    NC-Verilog has already implemented most of Verilog-2001 but is just now
    completing configs has caused the above predicament. It is regrettable but
    it was a business decision on the part of Cadence.

    Like I said in a previous email, I believe it is a dangerous precedent to
    invalidate a legal interpretation of the standard and any working
    implementations of that interpretation to make it easier for another vendor
    to put a different implementation into place.

    As a standards group, we CAN make this change. I do not believe it is wise
    to make this change. Do you want 75% of the balloting entities to vote to
    remove or change the SystemVerilog data types and kinds four years from
    now? Backward compatibility has generally been considered to be almost sacred.

    >As I mentioned in an earlier email, a compromise might be possible that
    >takes advantage of `begin_keywords. However, that compromise needs to
    >take into account that in practice, those keywords didn't really need
    >to be reserved until configs were allowed in Verilog source files. So
    >it needs to support the intermediate dialect that doesn't reserve them.

    This again is a side-effect of having implemented most of the Verilog-2001
    standard and saving configs for last. I sympathize for the NC-Verilog
    predicament.

    >Steven Sharp
    >sharp@cadence.com

    Regards - Cliff

    ----------------------------------------------------
    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 : Mon Apr 25 2005 - 17:07:25 PDT and
    sponsored by Boyd Technology, Inc.