On Friday 20 November 2009, Anthony Shanks wrote: > have the global nodes feature been added yet?
This is the "other" email specifically addressing the global node issue. Please don't take these comments as opposition to the concept. Rather, there are issues that need to be addressed to make a proper implementation. Since it is strictly input related, all changes would go in the spice language plugin, specifically the "lang_spice_in.cc" and "lang_spice_commands.cc" files. To see what I am concerned about, consider this: Suppose I am using a subckt model I downloaded from somewhere on the net. It might be for something like an op-amp. Let's say it has 50 components and 20 internal nodes, and I don't understand it. Let's further assume that I am working on some kind of signal processing circuit that uses 6 of these op-amps. Maybe I might be using a TSMC model file with a bunch of "Lib" blocks .. an 8 meg file with subckts around those mosfets, with internal nodes. People do use those TSMC models with gnucap. Now, suppose one of those internal nodes happens to be named "foo". Does saying ".global foo" in the main circuit connect all of those "foo"s together? I think most users would be totally confused if this happens. Saying ".global foo" in both the subcircuit and caller solves the problem. That way it is agreed on both sides. But, I don't think this is the way to do it. Otherwise, how does the subcircuit know that the "foo" node has an external connection? How global is it really? Truly global? file scope? When a file is included by an include statement, does the global transfer into that file? What about by a "lib" statement? What about mixed languages? I think Hspice and Spectre implement it like a preprocessor directive, but I don't know because I don't have access to either. I am not arguing, yes or no, whether to do it or not. There is something about the requirement that I don't understand. There are some real implementation issues and I am looking for answers. _______________________________________________ Gnucap-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnucap-devel
