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

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