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
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
