[sv-bc] Re: Configs Intent - was: potential command line option

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