Re: [sv-bc] Keywords

Hi, Mac -

I am going to largely cede the first two "No" points to you, but I will 
take up the third point below.

At 03:10 PM 4/26/2005, Michael McNamara wrote:
>-- 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.

True. I did not think this one through. I was trying to figure out if 
someone would want this capability. Mark Hartoog may have a worthy example.

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

Again, True. I did not think this one through. Same reasons as before.

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

Not quite. If you look at the slides I emailed to the reflector on 
4/20/2005, look at the last slide.

I should only have to execute the command:

ncverilog lib.map (this may require a switch or this file may be read 
automatically) and one of the three config files.

The compiler now has enough information to gather up all the design files I 
need to run this simulation. Pretty sweet!!

If the lib.map file is in the simulation directory and if my tool reads the 
lib.map file automatically in theory I can run three different 
configurations by executing the commands:

ncverilog rtl.cfg
ncverilog gates.cfg
ncverilog mixed.cfg

And I never had to modify any source files to run these simulations 
(without the mixed.cfg file, I had to add `uselib commands to my addertop.v 
source file - UGLY!)

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