Re: [sv-bc] Keywords

-- On Apr 26 2005 at 11:49, Clifford E. Cummings sent a message:
 > To: sv-bc@eda.org
 > Subject: "Re: [sv-bc] Keywords"
 > At 10:56 AM 4/26/2005, Michael McNamara wrote:
 > >  Looking forward, most seem to agree from an engineering perspective
 > >  that keeping config blocks in their own file makes the most sense.
 > >
 > >  (Quick Poll: does everyone agree to this?)
 > 
 > Yes and No.
 > 
 > Yes - from a methodology approach, I agree that it is generally good 
 > practice to keep configs in a separate file, and I will continue to teach 
 > this in my classes.
 > 
 > No - There are times when a quick-test will throw a config, a simple 
 > testbench and a design module or two into the same file to test a concept. 
 > A requirement to build separate files for concept-testing is
 > annoying.

What will the config include in it in this case? All that it can
talkabout is that a tool should find a particular module from a file
with a name of a certain pattern, or in a certain directory.  If all
is in one file, what one can include in the config file is pretty much
of no value.

 > No - It is sometimes useful to put the configuration, testbench,
 > and design files into a single file and send it to a colleague and
 > tell them to just run the file with your Verilog simulator. It is
 > also sometimes easy to package a problem to send to a vendor this
 > way, instead of sending the tar-ball and Makefile.

Again:

Perhaps you missed this, but with an "all the design in one file"
approach, the config block is pretty much useless.  

What config allows you to do is tell the compiler to use the module
definition for "dff16" from the file that matches the pattern
"dff16*.v" from the directory "rtl" instead of the from the file that
matches the pattern "dff16*.vg" from the directory "gates".

If everything is in one file, then config is moot.  If you use configs
you need to have at least three files. (one file holds the base design
with all but one of the modules of the design defined, and also holds
the config specification; and the second and third files are alternative
implementations of a module of the design.  The config picks one or
the other these alternative implementations).

 > 
 > No - It is very useful to replace -v  -y  +libext+.v  and some -f command 
 > line switches with configs, without the requirement to add different 
 > command line switches. Keeping configs in the Verilog input stream makes 
 > this possible.

Same response.

 > 
 > The context sensitive config idea does have merit. Separate email for that.
 > 
 > 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
 > 
 >