gnucap-devel
[Top][All Lists]
Advanced

[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.






reply via email to

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