Re: Configs Intent - was: potential command line option

From: Brad Pierce (Brad.Pierce@synopsys.com)
Date: Wed Apr 20 2005 - 20:58:51 PDT

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

    In SystemVerilog these semicolons are optional.

       http://www.eda.org/sv/Changes_draft6/LRM_Changes_A_BNF.html

    -- Brad

    -----Original Message-----
    From: owner-btf@boyd.com [mailto:owner-btf@boyd.com]On Behalf Of
    Shalom.Bresticker@freescale.com
    Sent: Wednesday, April 20, 2005 8:22 PM
    To: Clifford E. Cummings
    Cc: btf@boyd.com; etf@boyd.com; sv-bc@eda.org; sv-ec@eda.org
    Subject: Re: Configs Intent - was: potential command line option

    Regarding the semicolons at the end of the statements, there is already an
    ETF
    issue on this. In fact, I think there are two. I think there is one issue
    (# 372 ?), which lists this as one of several config issues, and I think
    there
    is another one ( 5xx ? 501 ?) which is dedicated to this issue.

    Shalom

    On Wed, 20 Apr 2005, Clifford E. Cummings wrote:

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

    --
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 - 20:35:53 PDT and
    sponsored by Boyd Technology, Inc.