On Fri, 2008-12-26 at 17:52 -0500, al davis wrote: > On Thursday 25 December 2008 10:59, Stuart Brorson wrote: > > Good point. But doesn't gnucap handle SPICE netlists? If I draw up > > some example circuits, and then netlist them using spice-sdb, doesn't > > the resulting .cir file "just work" in gnucap? > > sure .... in the same sense that DOS software runs on windoze.
Microsoft Windows? Witty parodies like "Micro$oft" and "windoze" don't make us look clever. I for one would like to see Windows as one of the entire gEDA suite's supported platforms. I'd like to think that we can be above all this OS rivalry and focus on writing decent cross-platform software which is good at its job. > I have hoped for a long time that we would shoot for more than that. Al, Point us to the specification of the non SPICE format, which gnucap supports, and we'll write a netlister. I already started a customised verilog-a netlister, the output of which gnucap can read, however I fell down on the following points: 1. gnucap seems to be picky about where and how it encounters comments and white-space when it reads "verilog" format. 2. I couldn't make the verilog syntax for gnucap work with current controlled sources. A specification of legal syntax which gnucap's parser currently accepts would be useful here. I realise you said in the past it would be better to fix gnucap's parser, but lets get something working _now_. If we accept that gnucap's parser supports a restricted sub-set of verilog syntax, we can make our netlist output compatible - and I can commit it as the "gnucap" netlister. (Or does gnucap have a different preferred syntax now?) If you point us to the required / optional attributes for a sensible set of basic components, and we can produce gnucap targetted symbols where those attributes are present and ready to fill in. With these details, we will be in a position to emit good circuit models for gnucap. Without that, and without anyone such as yourself taking a real interest in driving gnucap + gEDA adoption forward, it won't happen - so stop jumping on everyone who wants to use "SPICE". There is already a working "spice" netlister in gEDA, symbols for spice basic models, and users who _use_ this work-flow. Just telling them gnucap is better won't make them switch, even if it _is_ better under the hood. > If we want gEDA to be more than just schematic and board layout, we need > to consider having more tools work together, in a way that fully > realizes the best of them all. Working with gnucap only in the > backward compatibility mode doesn't do that. Treating gnucap and > ngspice as equal doesn't do that. There appears to be continual conflict, as whenever anyone mentions the admittedly abused term "SPICE", with the intention of using ngspice or some commercial spice variant, we get a sales pitch for gnucap, and how it is (or is going to be) better. Right now, "SPICE" compatibility mode is the only documented gnucap input format, and the only one which a stable (or at least non-developer) release of gnucap has supported - so don't jump on people for thinking that is how we're supposed to interact with gnucap, or for wanting to use a documented work flow. gnucap needs a gEDA netlister, and symbols to enable a gnucap workflow. We also need guidance on what a gnucap workflow looks like (or should look like). You need to engage with us positively to make that happen, rather than complaining that it hasn't yet. I've already got most of the work done for a "gnucap" netlister, and I believe I sent it to you at some point. If you want to see that as the preferred input format, either finish the netlister and ask us to release it, or give us the specifications and encouragement required to get it finished. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
