[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] netlist translation via XML/XSLT
From: |
al davis |
Subject: |
Re: [Gnucap-devel] netlist translation via XML/XSLT |
Date: |
Mon, 11 Sep 2006 14:43:35 -0400 |
User-agent: |
KMail/1.9.4 |
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.