gEDA-dev: Fwd: google soc

[al davis]

On Tuesday 29 May 2007, John Doty wrote:
> It is very important to me that the gEDA tools remain
> separate. I   work with customers who use a variety of tools:
> it is *very* useful to be able to insert gEDA as needed into
> a foreign design flow. That's why I'm interested in seeing
> flexible translators like gnetlist rather than an integrated
> plugin system.
>
> Of course, gnetlist can surely be improved, and other sorts
> of   translation could be handy.

gnetlist is a plugin system, with plugins written in scheme.  It 
has a single input and multiple outputs.

What I was talking about is to handle multiple input formats, 
and can easily be a standalone translator.  My starting point 
really was gnetlist.  Take it a step further and make the input 
pluggable too.  That program will exist. 

The original target of the whole thing was to move in foreign 
formats.  My original proposal was exactly a stand-alone 
flexible translator that generalizes both ends of the path, in 
both directions.

It could be built on the gnetlist code, with scheme plugins.  
That was my original intent.  If at the time someone stepped up 
to do that, it would have gone that way.  As it turns out, it 
is being built a different way, with C++ plugins instead of 
scheme plugins.  Development is going well, but there are still 
some hacks.

Actually, my original proposal was to make a gnetlist like 
program, possibly derived from gnetlist, that would use VHDL (a 
language with a published standard document that is not tied to 
any particular tool) as the source format, and essentially keep 
the gnetlist output plugins.  Then make another specifically 
the other way, everything to VHDL. There is requirement that 
the two steps of translating a format to itself must be 
lossless, as correctness check.

If you imagine what these two programs do, it becomes apparent 
that they have data structures in common.  So, why bother with 
the intermediate format?  Use two plugins, one for in, one for 
out.

The point that seems to be the tripping point is to take it 
another step further and make that program provide a linkable 
interface, so I can link to that and eliminate the need for the 
simulator to deal with files at all.  Originally, I didn't want 
to go this far, but it turns out to be the easiest way for 
gnucap to deal with things like the multitude of Spice formats, 
which have been a major headache.

I did consider just adopting Verilog-AMS as the format for 
gnucap, and translating everything in, including the "dot" 
commands, reverse gnetlist style.  Perhaps I am wrong here, but 
I don't think Spice users would like this system.  Actually a 
few spoke up rather loudly.  I also heard from those who 
thought VHDL, not Verilog, should be the native language.

> Redesigning gEDA around a particular simulator would be bad.

I agree absolutely.  It's even worse that you think!  Designing 
around a particular simulator really means either designing 
around a particular version of it or everyone keeping in sync 
for years to come.

Take it a step further and substitute anything else (schematic, 
layout, synthesis, ...) for "simulator" in that statement.