Configs Intent - was: potential command line option

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Apr 20 2005 - 18:03:07 PDT

  • Next message: Dave Rich: "RE: FW: New Mantis Issue #667 for V-1364"

    Mea culpa!

    (1) I wrote the Verilog-2001 BNF. The intent was to allow config files into
    the Verilog input stream and I apparently did not get that added properly
    to the BNF (aren't you glad Brad has taken over the BNF - I am!!) -
    translation: the Verilog-2001 BNF is broke if people are interpreting that
    config files cannot be read with the Verilog input stream.

    (2) I rallied the users to request configuration files as part of the top-5
    at Kurt Baty's 1996 Birds-of-Feather meeting at IHDL.
    I was tired of the gosh-awful-ugly and difficult to use `uselib directives
    that we had to add to source code to specify a different simulation
    configuration. There was no way I wanted `uselib to find itself into the
    standard.

    (3) Myself, Kurt Baty and I believe Mac (Mike McNamara) spent almost two
    years to come up with the original proposal of some really ugly
    +command-line switches to handle different configurations. Guys like Stu
    barfed all over that idea (although I was not appreciative at the time, I
    am now glad that Stu lost his cookies over the matter!).

    (4) Tom Fitzpatrick, then with Cadence, donated a Cadence proposal for
    configurations that did not involve command line switches. Tom and I
    worked-on and battled-over the proposal. I prevailed in removing "views"
    until the committee could be convinced that customers really wanted views
    (made Tom plenty mad at me back then!)

    (5) The proposal keywords were modified to allow Verilog-VHDL co-language
    tools to recognize "configuration" as a VHDL keyword and "config" as a
    Verilog keyword. The intent was to permit reading of configuration files in
    the Verilog input stream to remove the need for -v -y +libext+.v and most
    -f command line switch dependencies (and it does!) As a user, I did not
    want (and I still really do not want) to be required to use any additional
    command line switches to read configurations. This is hinted at in section
    13.4.4 where it notes that the config file can be specified on the command
    line.

    (6) I had also hoped that vendors would automatically read a lib.map file
    from the directory where compilation was invoked, so I would not have to
    specify a command line switch for all library map files (this shows up in
    Verilog-2001 section 13.2.1, 2nd paragraph). I don't think any vendors
    allow this (darn!)

    I have attached a few slides from my Advanced Verilog class that show how I
    wanted configs to work. You will notice that the example names closely
    match the example names in the standard, because I used my slides to help
    write the examples in the standard.

    (7) As a use-model, I fully expect to keep configs in a separate file from
    the Verilog source code, but I would like configs to be part of the input
    stream. Now that I know there is an implementation that does just that,
    that would continue to be my first choice.

    (8) About library mapping files calling configs, I don't think we thought
    that through very well. I could support modifications that helped add sense
    to that capability. Remember, unlike SystemVerilog where vendors have
    donated working technology and have been implementing and finding the warts
    before we have P1800, for Verilog-2001 vendors participated to make sure we
    had something that would be work-able if/when they decided to implement it.
    I think there are plenty of warts in Verilog-2001 for this reason (we did
    our best to avoid problems but until there was an implementation, we could
    and did make mistakes).

    (9) I had a number of typos in the configs section - these should be fixed
    no matter what we do.
    TYPOS:
    Section 13.5.2 - cfg1 example - design statement is missing a ";"
    Section 13.5.2 - cfg2 example - design statement is missing a ";"
    Section 13.5.3 - cfg3 example - design statement is missing a ";"
    Section 13.5.4 - cfg4 example - design statement is missing a ";"
    Section 13.5.5 - cfg6 example - instance statement is missing a ";"

    BNF TYPOS - the BNF does not show the requirement for the ending ";" in 5
    places. I recommend putting them in the config_rule_statement production
    (all 5 ";"'s). Then update Syntax box 13-4 in section 13.3.1 with the same
    correction.

    A.1.2 Configuration source text

    config_declaration ::=
         config config_identifier ;
         design_statement
         {config_rule_statement}
    endconfig

    design_statement ::= design { [library_identifier.]cell_identifier } ;

    *** Add a semi-colon after "..._clause" (5 occurrences)
    config_rule_statement ::=
         default_clause liblist_clause
       | inst_clause liblist_clause
       | inst_clause use_clause
       | cell_clause liblist_clause
       | cell_clause use_clause

    default_clause ::= default

    inst_clause ::= instance inst_name

    inst_name ::= topmodule_identifier{.instance_identifier}

    cell_clause ::= cell [ library_identifier.]cell_identifier

    liblist_clause ::= liblist { library_identifier }

    use_clause ::= use [library_identifier.]cell_identifier[:config]

    =================

    This is what was originally intended. Now we need to figure out what we are
    going to do to clarify or fix configs. Sorry for the mess!

    Regards - Cliff

    At 10:33 AM 4/20/2005, Randy Misustin wrote:
    >Hello Steven,
    >
    >Please allow me to make this a little less hypothetical:
    > * 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
    > * ModelSim's implementation of configurations allows the
    > configurations to be freely mixed in with Verilog source.
    > * Configurations are treated as first class design elements by our
    > system. They are compiled into design libraries right beside modules and
    > primitives.
    > * 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

    ----------------------------------------------------
    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 : Wed Apr 20 2005 - 17:44:27 PDT and
    sponsored by Boyd Technology, Inc.