[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Plug and play with with ngspice/hspice syntax and oth
From: |
al davis |
Subject: |
Re: [Gnucap-devel] Plug and play with with ngspice/hspice syntax and other questions |
Date: |
Fri, 20 Nov 2009 16:47:44 -0500 |
User-agent: |
KMail/1.12.2 (Linux/2.6.26-1-amd64; KDE/4.3.2; x86_64; ; ) |
On Friday 20 November 2009, Anthony Shanks wrote:
> I haven't used gnucap in quite a while so my questions might
> be a bit out of date.
>
> Last time I used gnucap, it wasn't quite a "plug and play"
> replacement for standard spice syntax in regards to the
> probe and simulation commands. As I recall the order was
> switched (you had to put your analysis type (as in .tran or
> .dc) in before the .probe command. In other spice simulators
> the .probe line comes before the analysis type. Has this
> issue been addressed yet? Also, have the global nodes
> feature been added yet?
Making it true plug and play compatible gives up a lot, and
takes a lot of developer time to duplicate all of the bugs. The
various spice's are not absolutely compatible with each other.
Having said that, since the entire user interface is defined by
plugins, there is nothing (other than time) stopping anyone who
wants to make a plugin that will provide complete compatibility.
I understand the need, but there are lots of other needs too.
The probe and simulation order is not switched. Spice doesn't
care, and loses the capability you can have when you can have
with real scripting. Again, you could easily make a plugin that
would give you exactly what you want.
The global nodes "feature" is also an interface issue, that can
be defined in that same plugin. There are some questions that
need to be answered, that I will address in another email.
All of this would go into a "language" plugin. There are three
now. Eventually, I can see a dozen or so for compatibility with
various other tools. The syntax doesn't need to be spice-like
at all.
My highest priority for now is to make a stable release with
full plugin support, and separation of library and applications,
so you can have a stable base with a clean interface to build
on.
There is full plugin support in the development branch, but as
shipped, the default set of applications (plugins, models,
commands, etc) are static linked by default, so it is not clear
where the border is.
If you want to help, by making language plugins for
compatibility with Hspice and NGspice, they would be most
welcome. This is an open invitation to anyone to contribute by
making a plugin for something important to you.