|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Mon Mar 17 2003 - 10:37:20 EST
Dear Charles, > 2. On a seperate but related subject, I am trying to extract a spice > netlist. I can load an inverter from say the UKANS web site library > "invf100.mag" and "extract", followed by "exttospice" from within magic. The > invf100.spice file has L & W filled in, but AD, AS, PD and PS are all zero. > I have tried just drawing poly over ndiff with various tech27 files and I > get the same thing (L,W OK, areas & perims are zero). There must be a trick > to get non-zero areas and perimeters from the extraction. I have studied the > .ext files and they seem to make sense, its just the .spice that has zero > areas & perims. The output of zero area and perimeter is "correct" as far as exttospice is concerned. Exttospice avoids redundantly specifying parasitic capacitance on transistor sources/drains by piling all of the area and perimeter for a node (network) onto one transistor (element) S/D connected to that node, and leaving all the other nodes with zero area and perimeter. You can pass the switch "-d" to exttospice (and ext2spice, in the non-Tcl version) which distributes area and perimeter evenly among devices connected to a single node. As far as I can tell, this switch is undocumented. I made one change in either magic version 7.1 or 7.2 in which I uncommented a line of code which outputs a "short" node merge record to the .ext file. This "short" form (with no area/perimeter values) is not strictly according to the .ext file format spec, and "exttospice" and "exttosim" flag it with a warning. I am not aware of any difference in output from previous versions other than the warning. Assuming there isn't any, I have removed the warning print statement from exttospice and exttosim in the latest version (not yet posted; probably will be posted next week). More importantly than the area/perimeter warning, I have rewritten several things in the exttospice and exttosim code. There was also a message "no such node" for "global" nodes "Vdd!" and "GND!". Labeling Vdd and GND with exclamation points is okay for everything internal to magic, but I've found it doesn't work well with other applications (as a bad example, archaic SPICE versions which want to see "0" for ground). The Tcl-based version provides a much better way to handle global nodes: Set global variables "$GND" and "$VDD" in Tcl to match the actual names of the ground and power nodes in the layout. While I was going through that code, I found some other incorrect behavior with exttospice and exttosim which comes from their original instantiation as standalone programs. One is that the devices "nfet" and "pfet" are built-in, with hard-coded values, instead of being taken from the tech file. So all devices are effectively extracted as scmos devices, regardless of the technology (unless you pass a slew of detailed information through the command-line arguments). In addition, one of the node resistance classes was hard-coded to a value which appears to come from a long, long ago version of the scmos tech file, ensuring that the well resistance under pMOS devices is way, way too low (the resistance class is the class for metal1, not nwell). I'm not sure how often this would show up in simulation. But it underscores the need to have ext2spice and ext2sim as part of magic, not as standalone programs, so they can pick up all relevant information about the technology. I will write up a set of tutorial files before next week. I have tentatively scheduled a seminar at APL about improvements to magic & friends, which forces me to have some kind of usable documentation before March 24. > Well, I downloaded magic-7.2.30, irsim-9.6.5 & netgen-1.2.0 to one of my > systems today. I was able to compile with the tcl option magic and irsim, > but the netgen tcl compile fails with an error in tclnetgen.c regarding too > few arguments to strncmp in line 634. It also has a warning that > NETGEN_VERSION is redfined (the two definitions are in netgen.h and > ntk2adl.c). I can run a non-tcl compile on netgen and it completes > successfully. I worked over netgen last week and was making great headway with it, so I will have to check for those two errors. I didn't mess with the code around the strncmp() error, so I suppose it's still there (should be "strncmp(Tcl_GetString(objv[1]), "list", 4)"). I didn't do a "#include <string.h>" at the top of tclnetgen.c, so my system doesn't check the argument list. Apparently your OS includes "string.h" by default. The NETGEN_VERSION redefinition should not be coming from "ntk2adl" (don't know why it was reported that way), but from dual definitions in "netgen.h" and the top-level "Makefile". Delete the one in "netgen.h". Thanks for your bug reports and continued interest in the program development (in spite of the occasional flakiness of the alpha code). Regards, Tim
|
|
|
|