gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] language plugin help


From: al davis
Subject: Re: [Gnucap-devel] language plugin help
Date: Sun, 15 Apr 2012 14:17:14 -0400
User-agent: KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; )

On Sunday 15 April 2012, Felix Salfelder wrote:
> I was wondering about why anyone would want to use gnetlist,
> when gnucap can read the geda/gschem netlists.

I think the real answer to this one is to support non-gnucap 
users of geda.

Ultimately, a new program based on the gnucap library could 
support that need, but it does not exist yet.  This new program 
would be  a command line program that simply reads using one 
language plugin, and writes using another, thereby providing 
translation.

From a geda/gschem perspective, the goal is to provide an in/out 
path for geda/gschem.  Other paths are nice, but not primary 
goals.

From a gnucap perspective, the goal is to provide an in/out path 
for gnucap.  Other paths are nice, but not primary goals.

Is it geda/gschem's responsibility to provide a path from kicad 
to gnucap?  Obviously, no, but that doesn't mean it can't.

Is it gnucap's responsibility to provide a path from geda/gschem 
to ngspice?  Obviously, no, but that doesn't mean it can't.

There is some redundancy here ...  the responsibility for the 
path between geda/gschem and gnucap is shared.  Either or both 
could provide it.

The responsibility for the path between Kicad and gnucap is 
shared.  Either or both could provide it.

If gnucap provides the geda/gschem to gnucap path, and the kicad 
to gnucap path, a geda/gschem to/from kicad path will also come 
out of the work.  Such a path is nice, but not a primary goal of 
gnucap.  Let's say it could be a secondary goal.

The promise of a geda plugin for gnucap is not a reason to stop 
work on the gnetlist verilog export plugin.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]