Re: [Gnucap-devel] New Developer

[al davis]

On Monday 19 May 2014, Aidan Macdonald wrote:
> I would like to develop for Gnucap. I have several years
> experience programming in many languages including C and
> C++. I have designed a small hardware emulator for GPIB
> Controllers. I am a Computer Engineering and Physics student
> at UC San Diego.

That's great .. welcome.

Where to start?  It depends on what you can do, and what you 
want to do.

I think mostly you should look in the direction of "increase 
functionality".  One side of this is that there are a lot of 
features other simulators have.  It would be great to have them 
here too.  This could be porting existing code to the gnucap 
architecture, or something totally new.  Another side of this is 
original research that nobody else has.


Felix mentioned a couple of things as "code cleanup".  I will 
fill in some details and add one more.  These are likely to be 
more difficult.

Gnucap makes serious use of plugins, and places a very high 
emphasis on code modularity, minimalism, and thorough testing.

It didn't always use plugins, so there is still some work in 
transition.

The first he mentioned "get rid of obsolete_* functions" refers 
to changes in support of parsing different formats, the 
"language" plugins.  Device code is designed so each device 
knows nothing about syntax, because it all comes from the 
language plugins.  The transition is not complete.  There is 
some lingering code from the old way, mostly in the bm_* 
plugins, marked with long names including the word "obsolete" or 
"obsolete_callback".  What we a referring to here is to finish 
the job.  The issue .. it isn't just changing to the new form.  
There are syntax issues that don't quite work in the new form.  
The most prominant one is specifying arrays of data, a syntax 
feature used by Spice compatible functions like PWL.  That is 
why I haven't already done it.

The second he mentioned is "rearrange output plugins".  It's not 
just rearrange.  There are not output plugins, but we need them.  
The output here is displaying the results of an analysis.  In 
the old code, it's in with the ac/dc/tran code.  It needs to be 
plugins.  Very important!!

One more I will add is to make the logic device code pluggable.  
There are modularity issues here.  Gnucap is the first simulator 
ever to properly support the concept that Verilog-AMS calls a 
"connectmodule", but it isn't plugable and has its own syntax.  
It predates Verilog-AMS by many years.


This is just a few.  .. fairly big ones.