On Jan 21, 2008, at 3:51 PM, a r wrote: > On Jan 21, 2008 8:47 PM, John Doty <[EMAIL PROTECTED]> wrote: >> >> It seems like netlists, not schematics, are the basis here. I don't >> see why that is at all a problem for gEDA as currently structured. >> Either a separate tool or a gnetlist back end could do this. I don't >> see why you think a spice-subcircuit-LL component could get in the >> way here. > > I don't want to put backend specific components on the schematic. If > the "spice-subcircuit-LL" is _the_ way of making hierarchical > schematics, and "spice-subcircuit-IO" is _the_ way of connecting them, > then I have no objections against using them. But for now they look > strongly tied to the spice-sdb backend only.
Yes. That's the way it works. Each specialized netlister has its specialized needs. I'd rather use source= hierarchy too, but it doesn't work well for my flow, while Stuart's approach does. Results have priority over minor convenience. > >> I don't know what open source tools exist here. It would be >> interesting to investigate incorporating them into a gEDA flow. > > The flow is very rigid. You still _have to_ use the "blessed" flow, at > least for sign-off. Sure, you can use some cheaper tools meantime but > to really make a difference these tools would have to be 100% > compatible with rule sets provided by the fab and work reasonably > well. Very similar thing happens with simulators. For sign-off you > _must_ use the simulator (often in a specific version) your fab > requires (together with their models). Otherwise, in the best case, > you are left without support. Osaka U. has educational licenses to tools that I can't afford (VLSI is a sideline). So we often run the same sims on different simulators (hurray for spicepp!). Ngspice is actually pretty good: not as touchy about minimum conductance settings as the big $$ simulator. > > Good place for gEDA to start spreading in this industry is to > concentrate on design entry tools (schematics editor, netlisters), Works great, and I have the silicon to prove it. > logic simulators and data viewers (simulation results etc). This is > because these tools are relatively simple, non-critical, easy to adopt > and its commercial counterparts can be expensive. Analog simulation is > a next step - this is more difficult because of higher compatibility > requirements but still it would be possible to compete with commercial > simulators by price. Ngspice is actually pretty good: not as touchy about minimum conductance settings as the big $$ simulator, and otherwise getting equivalent results. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
