Re: New Developer
al davis <[email protected]>
| Newsgroups | gmane.comp.gnu.gnucap.devel |
|---|---|
| Message-ID | <[email protected]> |
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.