On Jan 20, 2008, at 2:33 PM, a r wrote:
On Jan 20, 2008 6:19 PM, John Doty <jpd@xxxxxxxxxxxxx> wrote:On Jan 20, 2008, at 6:51 AM, a r wrote:1. It forces me to add a simulation card to the schematic. In generalcases that something I'd like to avoid (it is OK for testbench schematics, though).I don't see why that's a big deal.- clean schematics are needed for LVS,
What's LVS? Please don't assume we know your jargon.
- different simulators are used.
That's why we have different netlist back ends, and it's also the reason for the existence of postprocessing scripts like spicepp (not part of gEDA, but plays well with it).
2. All nested models or ".include" cards (if "-I" option was used) areadded inside the .subckt. That may cause problems with spice simulators that do not like such nested constructs.Indeed, that's an annoyance, not only for simulation but for layout. The layout contractor I work with wants to see each cell in the netlist exactly once, at top level, not nested. But a little postprocessing gets the job done here.3. There are special "spice-subcircuit-IO" components used for making subcircuit pins. Does it mean the netlister cannot cope with "normal"instance pins?There are a couple of different ways to do hierarchy. If you use source= to associate the symbol to its subcircuit, you use the symbols in the "io" library to make your connections in the subcircuit schematic. In this case, the netlister expands all hierarchy automatically, making a flat netlist. On the other hand, if you use the model-name= attribute to make the association, you need to use the spice-subcircuit-IO symbols in the subcircuit schematic. In this case, you won't get a flat netlist, but if you also use the file= attribute you'll get a nested hierarchical netlist, which I don't find terribly useful.I would prefer using "source=" attribute. As I mentioned in the other thread I like this concept (except for current library search strategy). Also, I would like standard (BTW, are they "in"/"out" or "input"/"output"?) pins instead of that spice specific pins.
OK, so you're requesting a merger of the different ways to do hierarchy. That would be nice.
One issue for SPICE is that the pin sequencing in this approach is in the symbol, not the schematic, so the schematic alone does not contain the information. An interesting way to solve this might be to adopt a convention from my little corner of the VLSI world (Japanese high energy physics and astronomy!). We like to put the symbol for the subcircuit on the subcircuit schematic as a graphical "comment" (graphical=1 in gEDA) as in the following example:
Attachment:
Pump.pdf
Description: Adobe PDF document
The netlister could obtain attributes from such a symbol.
One of the difficulties is that SPICE pin associations are by pin order (pinseq=), not by name. If you're importing a macromodel or cell from outside the gEDA world, you won't even have a subcircuit schematic.All EDA tools I know use pin numbering just for the sake of interfencing with external files (spice/verilog/vhdl netlist etc.). Often this pin numbering can be automatically retrieved from the netlist. This, in most cases, is not an issue if a schematic view is available.
Remember that gEDA is a flexible toolkit, not an inflexible integrated tool. To keep that flexibility, it's important that most of the files be "external" in the sense I think you're using.
John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd@xxxxxxxxx
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user