Re: [Gnucap-devel] missing info in the models tarballs.

[al davis]

On Saturday 24 February 2007 03:43, David Fang wrote:
> I strongly recommend
> GNU libtool -- it works like magic; 

Go for it.   I have not used it.  I agree that it is needed.  
What you see now is a temporary hack to get something out.

To give you an idea of the long term goals ....

There are about 500 more of those spice models. Whatever you do, 
it must be easy to propagate to all of them.  That is, a 
typical EE who downloaded the Spice code from the net should be 
able to do what is needed, in less than 5 minutes.

Not all of them are distributed.  There are in-house models, and 
some that are available only with strings attached or for sale.  
Consider something like the EKV model.  They will give you 
Spice source under non-disclosure.  Therefore, I won't look at 
it, and won't distribute it.  If a user is willing to sign the 
nondisclosure agreement, they should be able to do the work 
without asking for help.  There is also an important lossy 
coupled transmission line model that is for sale.  It should be 
easy enough that they are willing to do it.  I want gnucap to 
become popular enough that they feel they must do it.  I want 
gnucap to become the preferred environment for research in 
modeling.

Here's what we need:

step 1......

To start, go back to a simple one.  Take any of the gnucap 
source files listed in Make1 in the "can be omitted and 
supplied as plugins section".  I want to be able to hack one of 
them, then "attach my_file.cc" at run time.

The attach command will be modified to invoke make to build the 
object file.  As of now, it just uses "dlopen" to load it.  It 
should automatically build it if needed, through make.

The user should also be able to build the .so directly, by 
saying "make my_file.so", without writing a new Makefile.  Make 
does this now for executables.  It looks up default rules.  The 
configuration needs to set up the options, name extensions, 
etc.

step 2 ....

Extend that so it works for files that are built in two stages.  
For now,this is the ".model" files.  Eventually, this will be 
verilog and VHDL files also.

step 3 ....

Extend it so it works with single attachments that are made of 
multiple files.  This is the Spice files. At this point, some 
sort of Makefile for the set of files is obviously required.  
It should be no more complicated than the Makefile that I added 
to each Spice model.

step 4 ...

Extend it so it honors inheritance, and automatically tracks 
other plugins that are needed.

that's it, I think.

Does this make sense?

I think it means that configuration must be done as part of the 
core configuration.  Then that will automatically be used for 
all attachments.

All of this here must be considered to be something done at run 
time by an end user, like a netlist.  The simulator core might 
be installed in a public place, but this part is in user space.

Some changes to the core are needed.  These will be done.

What you see now is a checkpoint that I think is on the way 
there.  If some of it needs to be thrown away, and redone 
differently, it will be done.

If you can do this, it will really save me a lot of work.  
Otherwise I need to do it.