Re: gEDA-user: blue sky ideas : side-effects on circuit modelling?

[John Griessen <john@xxxxxxxxxxxxxx>]

Tim Golden wrote:
> I was just reading
>    http://www.lorentzsolution.com/technology.html
> and thought I would query whether or not the 'blue sky' intiative would
> have any side-effects in terms of SPICE modeling and beyond. In the
> abstraction of the parts layout could it be that there would be a
> backflow solution to SPICE models? I say backflow because gEDA currently
> flows from schematic to SPICE and to layout, but not the other way
> around.

Sure, those are long term goals behind some of the blue-sky DJ was discussing.
It's called blue-sky because it's not funded yet, which makes it kind of far off.
I keep exploring ways to make money on open hardware which would justify
spending on development of layout and simulation back annotation to
gschem, but I have not gotten there yet.

Even without the blue-sky list there are ways to get a good flow of info in
the schem-to-sim direction with the Verilog-ams gnetlist back end, and it is a complete
circuit description, so interactive simulation changes short of topology changes
could be translated and used to update the previous version of the gschem schematic.
The forward direction needs scheme/guile programming work still before gnucap simulations
of a Verilog-ams netlist exactly extracted from gschem works without problems.

Once the schem-to-sim direction is working well I think it will be easy to generate enough excitement
to get several people coding on ways to interface it with gschem that are productive.
The first way likely to get done is a command line script method of calling gnucap,
then waiting for a command from that instance of gnucap to import the current netlist into gschem
by calling a translator program.  The way that would look and feel is "collection of tools"
possibly with some reminders of the desired flow if the user sets it up that way.  A step by step
path from schematic to sim and back would go like:

1. start gschem, load circuit
2. call gnetlist with Verilog-ams backend from a gschem button, (or not)
3. start gnucap, using gnucap specific commmand line args to load the Verilog-ams netlist just created
4. Use gnucap specific commands to run simulation(s)
5. Use gnucap specific commands to save simulated data
6. View simulated data in whichever viewer you can get to run from a package or compile on your machine,
	gwave, kjwaves, etc, including just plain old gnuplot.  (gwave is supported package
on Fedora or Red Hat, but debian is problematic to get it compiled -- tries one's patience
and the debian package was broken recently...)
7. decide your netlist changes are good after viewing sim data and import the new netlist into gschem by
      running a translator program then load that new schematic name.

There is nothing standardized or agreed upon about this yet -- it is all do it yourself.
I can be hired to work on that though :-)

I think the idea of EM based verification is ripe.  We have MEEP and gnucap and they
are open and possible to move data between.  Have you got a budget for developing it?

John



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user