kicad-developers team mailing list archive
Mailing list archive
Re: Gnucap, kicad, and summer of code.
al davis <ad10@...>
Sat, 4 Apr 2009 03:35:04 -0400
On Friday 03 April 2009, Dick Hollenbeck wrote:
> The summer of code is only open to students right?
> This limits who can win the prize, but does not limit who can
> do the work. Its just that you have to be a student to get
> any money for it?
For anyone who hasn't applied yet, it is probably too late.
Google summer of code is for students. Some projects are
selected for funding, competitively. Last year, something like
1/5 of the applications were funded.
Maybe next year.
Even without funding, I still want to make Gnucap work with
Kicad, and would like help doing it.
> Required Qualifications:
> 1) Student
> 2) C++ experience
> 3) Kicad experience
> 4) Gnucap experience
or can learn fast.
> Even if such a person can be found, it is reasonable to
> assume they will come asking for guidance.
> My suggestion is to use D-BUS. The file formats in Kicad are
> likely to evolve and that will break code that relies on a
> stable format. A series of well designed D-BUS functions
> are likely to be more stable and immune from file format
Both approaches are valid.
Gnucap uses "language plugins" to read a variety of formats.
For now, the supported formats are Spice, Spectre, and Verilog.
There is a need for a stand-alone translator facility, using the
same plugins, which would provide separate translation
It is good that you recognize that the Kicad format will
evolve. That points to a need for a facility to convert it to
and from something that is stable and documented, with a
published document. I like Verilog for this. I can see using
the structural subset of Verilog as a general format for
netlist, schematic, and layout. I can explain better after I
get back home from travelling.
When the Kicad format changes, you will need a way to convert
files between the new and the old.
gEDA has a translator with plugins for the format being written,
but the input format is always the gEDA format, which causes
problems with its ability to evolve. The translator only
provides a one-way path out.
The translator I am thinking of could eventually provide an
import and export path for lots of other formats, including
Pads, Eagle, Qucs, .....
> So, would it then make sense for you to list your needs at
> runtime, since Gnucap would be considered a client of a Kicad
> service? By runtime, I mean in a situation where both
> Gnucap and Kicad are loaded and running concurrently.
A new plugin needs to be created that would provide the needed
communication. It must be a plugin so it can evolve
separately, and to stay out of the way when it is not being
> Maybe you can identify function declarations in psuedo code
> or (cidl) that you would need to make your end work at
> runtime. These can then be evolved into D-BUS interface
> documentation sets, and then we have provided some guidance
> to any one stepping forward, student or otherwise. Obviously
> the final implementation can exceed the requirements.
I am travelling now. I will answer when I get back home.
> That is my suggested path forward. It tries to protect
> investment of effort (by offering better but not perfect
> immunity from file format changes), and it tries to provide a
> path of maximum user experience at runtime.
It really is important to protect against format changes. That
is why it must be in a plugin.
You might want to use a Gnucap-type plugin system for Kicad. It
works really well.