Re: [Gnucap-devel] netlist translation via XML/XSLT

[al davis]

Thanks for the offer.  It is very much needed.

On Wednesday 06 September 2006 14:02, Andrew Plumb wrote:
> For a GPL'd set of tools, I think the approach I'll take is
> to create a simple lex/yacc-based parser to read SPICE format
> from STDIN and write XML to STDOUT.  Then anyone can use
> xsltproc to create/modify/enhance their own output format, or
> possibly re-use the parser code to write directly to a
> BSD/MySQL database or equivalent for other funky stuff.

Something like the PBM graphics stuff.  Convert everything to 
PBM, then pbm to everything.

That looks like a lot of work.  My interest is only to 
Verilog-AMS, but I see the benefit, especially considering the 
gEDA project.  The intermediate format could include schematic 
and layout info too.  The gEDA project now uses "gnetlist" 
which uses "guile" (lisp) scripts to define the output.  It is 
one-in, many-out.  It doesn't work very well, but it is the 
best we have.  If you really do it as you say it might be a 
better replacement for gnetlist.

For gnucap, as I said, my need is to convert to Verilog-AMS.  I 
see that as many inputs (HSPICE, PSPICE, NG-SPICE, XSPICE, 
LT-SPICE, etc.) which are all different, often in trivial ways 
just enough to be annoying.  If such a translator exist, gnucap 
could become a Verilog-AMS simulator, without the baggage of 
other stuff.

There are also some really different formats (Spectre, Mast, 
Touchstone, VHDL, IBIS, ...).  They are lower priority, but I 
mention them here to point out that eventually many input 
formats are desirable.

> Probable usage examples:
>
> spice2xml < netlist.cir > netlist.xml
> spice2xml -i netlist.cir -o netlist.xml
> spice2xml -i netlist.cir > netlist.xml
> spice2xml < netlist.cir -o netlist.xml
> cat netlist.cir | spice2xml > netlist.xml

There is a sort of standard form for this.  I am not an expert 
on it, but it should probably be whatever is accepted as 
standard for "filter" programs.

> ...then all you would have to do is:
> xsltproc spice2vams.xsl netlist.xml > netlist.vams
> ...where spice2vams.xsl is the XSL transform that converts
> the output of spice2xml into a Verilog-AMS equivalent.

A second step, requiring xsltproc to be installed.  Does this 
limit portability?  

A wrapper script could make the whole conversion look like a 
one-step process.

I have considered that something like Verilog-AMS or VHDL-AMS 
would make sense as the intermediate format.  Some programs 
could actually use it directly.

The issue I have with XML is that it really doesn't say much.  
It is really just a base on which you can build a language.  It 
does the easy part.  You still need to define what everything 
means and how it is organized.  You might as well make it 
C-like (with curlys), ADA like, or Lisp like.  I don't see the 
difference.

> For documentation purposes (e.g. scripted generation of
> design summaries), it would be useful to also have an
> equivalent vams2xml.  Experience has proven it makes a lot
> more sense (and saves a lot of time) to re-use the
> simulator's own parser so everything stays in sync, so that
> would be a lower priority on my part, not being familiar with
> that parser and all.

Gnucap's parser is a recursive-descent type built around a "CS" 
(command string) class, "argparse" library, that handles 
lexical analysis and parsing easily.  That really doesn't 
matter, because if you want to take vams as input, a translator 
could be a more complete implementation than a simulator.  The 
Spice parser is such a mess you don't want to build around it.

The simulator's own parser doesn't make sense here because the 
main need for a translator is to handle languages that the 
simulator doesn't.

On the other hand, the "argparse" library works well, and you 
might want to use it.

> I'll be doing my development work on my (Intel-based) MacBook
> Pro and check that it compiles on one of my Fedora-based
> machine.  That should help keep me out of any trouble w.r.t.
> work conflict of interest, since Mac isn't a supported
> platform. ;-)

I don't think that matters.  

I think most gnucap users are using some kind of Linux or BSD.  
Some that I know of use MS-Windows, with either cygwin, or a 
cross-compiled version using Ming.  I don't know of any using 
MS-Windows native, or compiling it with the MS compiler.