Re: [ng-spice] Proposed netlist format extension


To ng-spice@ieee.ing.uniroma1.it
From Al Davis <aldavis@ieee.org>
Date Thu, 1 Feb 2001 12:21:25 -0800
Delivered-To mailing list ng-spice@ieee.ing.uniroma1.it
In-Reply-To <AHFBELBMELODKAAA@hotbot.com >
Mailing-List contact ng-spice-help@ieee.ing.uniroma1.it; run by ezmlm
References <AHFBELBMELODKAAA@hotbot.com >
Reply-To ng-spice@ieee.ing.uniroma1.it

On Thu, 01 Feb 2001, GLAO S. Dezai wrote:
> I think we should not change the spice decks syntax.

In the simple case, I agree with this.  The dot form is an extension 
for new components.  For old components, either syntax would be 
accepted.  The "option" is not needed because lines without the dot 
are in old form.

When you look at the extended components, in all of the commercial 
simulators that claim to be "Spice" or "spice compatible" it is such 
a mess of incompatibility that it really needs a clean-up.  The 
commercial software companies won't do it because they want to lock 
you in.  They have even picked different incompatible letters.  For 
example, "B" is an IBIS model in HSPICE, a GasFET in PSPICE, a 
behavioral source in most Spice3 derivatives.  And everybody knows 
that the "W" element is a lossy transmission line!!!?

So, what letter should I use for an IBIS model?  Gyrator?  
Trans-capacitor?  Triode? SCR?

The dot form adds about a page of code, to dispatch based on the 
keyword, probably in the same file as the existing page of code that 
dispatches based on the first letter.  This is the only difference.


> 1) It is possible to write another parser for the dot form o any
> other langage and introduce a compatibility option 
> For exemple .option DECK=SPICEFORM
>  or        .option DECK=LANG2FORM
> Then the correct parser will be selected according ....

Spectre does this.  The problem is that you must choose between the 
rich proprietary language or the restricted traditional one.


> 2)The second possibility is the xspice one. The model A is
> a generic model suitable for anything

One problem with this is that in time, everything will begin with "A" 
or "X", depending on whether it was described in code model form or 
in subcircuit form.  What about other methods of installing models?  
Does the user of a model care about this?  I can see this developiing 
into a system where the first letter does matter, but has a meaning 
foreign to the typical circuit designer.


Here is another thought:

Go with the dots, which keeps the old syntax for all lines that don't 
begin with a dot.  (my original proposal)  Then add a command that 
allows the user to map letters to types, overriding the default 
mapping.  This would have the benefit that you could have user 
defined types (like a special kind of resistor) and still use the 
traditional notation.

al.

Partial thread listing: