[sv-bc] Configs & Modules in separate files - was: potential command line option

Hi, All -

New subject line to separate out the issues.

At 01:34 AM 4/24/2005, Michael McNamara wrote:
>On the face of it, from good software engineering principles, it makes
>a lot of sense to me to separate the files containing configs from
>files containing module definitions, ...

I absolutely agree and I teach it this way in Advanced Verilog training 
classes.

>... leads pretty
>good support via tranitive closure and the rule of least surprise to
>the expectation that Config BNFs should also be in their own files.

I agree that configs should be in separate files and thinking back on why I 
wrote the BNF the way I did is because I did not want to infer that modules 
could be nested in configs and configs could not be nested in modules. I 
still wanted both configs and modules to be read in the same Verilog input 
stream. Mea culpa!

The best evidence I can offer to show that config, endconfig and library 
were intended to be read in the Verilog input stream is the Draft-4 Annex B 
of the Verilog-2001 Standard that I sent with my email dated 4/21/2005. In 
that annex, we clearly showed that config, endconfig and library were 
intended to be Verilog keywords while all other config and library-related 
keywords were separated into their own keyword lists. Per vendor requests, 
we combined the keywords in Draft-5.

Any vendor following the draft standards for Verilog-2001 could very easily 
conclude from Draft-4 that configs and library's should be read in the 
Verilog input stream, especially since combining the keywords in Draft-5 
did not add any text anywhere prohibiting configs from being in the same 
files as a module. I believe ModelSim, as described by Randy, has correctly 
implemented the intended functionality.

>But finally, I return to the question as to why it would be a Good
>Idea to include module definitions in the same file as the config.  Is
>there a compelling reason? What use model is uniquely enabled by this?

I see no great compelling reason to include configs and modules in the same 
file (small exception described below). I do however see some very 
compelling reasons to include configs and modules in the same Verilog input 
stream. Having them in the same input stream gives me a powerful way to 
eliminate the need for -y  -v  +libext+.v+ and many of my -f file-list 
command line switches without the need to add new command line switches to 
accomplish the same goal. Passing a config file to my tool tells my tool 
which files I want to assign to which modules or which instances of modules 
for this configuration of my simulation. That is the intent and value.

Verilog also allows you to start a Verilog module in one file, continue the 
module in a second file, and finish the module in a third file, and then 
you must compile the files in the correct order, but it will work (EOF is 
just considered to be white space). I tell my students that, "if I EVER 
catch you doing this, I will take back your course completion 
certificate!!" (use a stern parental tone while uttering these words!)

For 99% of real designs, engineers will separate configs from modules 
without even being told to do so.

I also separate 99% of all Verilog testbenches from my Verilog design 
files, but there is the occasional testing of a concept where I throw both 
testbench and design into the same file, just so I can quick compile and 
test. I imagine I might do the same thing with configs to quick-compile and 
quick-test a concept. Throwing config, testbench and design into the same 
file is also a convenient way to pass an idea to a colleague for 
experimentation or to pass a bug to a vendor for testing.

Hope this helps.

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