Re: [sv-bc] Keywords

-- On Apr 26 2005 at 17:30, Clifford E. Cummings sent a message:
 > To: sv-bc@eda.org
 > Subject: "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.

Great!

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

I was a bit quick there, in truth.

 > 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

I don't have those slides handy, but if these config files contain
just a set of config blocks, then I agree with you, we are in good
shape.  I love the use model.  I will note however that:

% ncverilog -f rtl.cfg 

would deliver this simplicity today, and the +libext.vg stuff could be
buried in the rtl.cfg file, or the new style config block could be
there; I don't care as an advocate of symplicity.

If, to work, these files need to contain a few module definitions,
then we have more to talk about.

-mac