www.chiptalk.org - Forum - NCSU CDK - A possible bug in the NCSU CDK

www.chiptalk.org Forum Index

NCSU CDK

A possible bug in the NCSU CDK

Browsing this Thread: 1 Anonymous Users

Bottom

Previous Topic

Next Topic Register To Post

	A possible bug in the NCSU CDK	#1
Quite a regular Joined: 2005/9/27 10:52 From Columbia, SC Group: Registered Users Posts: 36 Level : 4; EXP : 76 HP : 0 / 94 MP : 12 / 2105	Hello again! The NCSU CDK is giving me another problem. The Analog Environment netlister is not replacing the "gnd!" net connection to the NMOS bulk terminal (for the 3-terminal NMOS symbol) to netlist global net 0, as it does for all the other gnd! connections. In other words, connections to "gnd!" (through the use of the gnd symbol in analogLib) on NMOS sources and voltage sources works fine, as these connections are shown to be connected to global net 0 in the netlist. However, the implicit gnd! connection to the bulk node (in the NMOS properties sheet) remains as "gnd!" in the netlist instead of being converted to global net 0. I've never had this problem using other PDKs. I assume this is a SKILL bug somewhere, but I'm not sure where to look. What SKILL file is run during the netlister phase? Anyone know how to fix this? Thanks, -Jason Posted on: 2006/2/2 12:57

	Re: A possible bug in the NCSU CDK	#2
Moderator Joined: 1969/12/31 17:00 Group: Webmasters Registered Users FAQ Admins Stats Admin Posts: 298 Level : 16; EXP : 14 HP : 0 / 378 MP : 99 / 48005	Hi, I'm afraid at this point all I can write is "works for me". I am using the 1.4 version of the PDK and IC51-41-USR2 on Linux. The netlisting settings are defined in the library CDF (Tools -> CDF -> Edit, then select the nmos device, roll down the dialog and click on Edit halfway down the page). The support for HSpice is built into Virtuoso so the Skill procedure that writes the final netlist ships with IC. I assume your system configuration is pretty similar to mine. If you have a small testcase, I would be happy to try it on my end. Thanks, Johannes Posted on: 2006/2/2 13:36

	Re: A possible bug in the NCSU CDK	#3
Quite a regular Joined: 2005/9/27 10:52 From Columbia, SC Group: Registered Users Posts: 36 Level : 4; EXP : 76 HP : 0 / 94 MP : 12 / 2105	Johannes, I just created an inverter design and netlisted it. I get the following netlist. // Generated for: spectre // Generated on: Feb 2 17:07:34 2006 // Design library name: temp // Design cell name: INV // Design view name: schematic simulator lang=spectre global 0 vdd! // Library name: temp // Cell name: INV // View name: schematic M0 (Z A vdd! vdd!) ami06P w=6u l=600n as=9e-12 ad=9e-12 ps=15.0u pd=15.0u \ m=1 region=sat M1 (Z A 0 gnd!) ami06N w=3u l=600n as=4.5e-12 ad=4.5e-12 ps=9u pd=9u m=1 \ region=sat simulatorOptions options reltol=1e-3 vabstol=1e-6 iabstol=1e-12 temp=27 \ tnom=27 scalem=1.0 scale=1.0 gmin=1e-12 rforce=1 maxnotes=5 maxwarns=5 \ digits=5 cols=80 pivrel=1e-3 ckptclock=1800 \ sensfile="../psf/sens.output" checklimitdest=psf modelParameter info what=models where=rawfile element info what=inst where=rawfile outputParameter info what=output where=rawfile designParamVals info what=parameters where=rawfile primitives info what=primitives where=rawfile subckts info what=subckts where=rawfile saveOptions options save=allpub As you can see, the NMOS bulk connection is left at gnd! and the other gnd! nets were changed to 0. I never understood why the netlister does this anyway. What's the problem with leaving "gnd!" as "gnd!"? Why change it? It serves no purpose as far as I can tell. Anyway, it seems as though I've been having this problem but just not noticing it until now. Spectre issued warnings for the floating NMOS bulk node, but the simulation still runs and the results seem to match what you'd get with a grounded bulk node. There are several work-arounds for this. The first is to use a 4-terminal NMOS and slap a gnd symbol to the bulk node. The second is to change the bulk node in the NMOS properties to "0". The third is to manually edit the netlist prior to simulation and replace all instances of "gnd!" to "0". Changing the NMOS properties is the easiest solution, but ultimately will prevent LVS from working, causing a mismatch between the bulk nodes in the schematic and layout (schematic=0, layout=gnd!). I checked the netlister settings but didn't see anything that would cause this problem. If I was a better SKILL hacker, I would change the scripts to prevent gnd! to 0 conversion during netlisting, since doing so seems silly anyway. Thanks, -Jason Posted on: 2006/2/2 15:17

	Re: A possible bug in the NCSU CDK	#4
Moderator Joined: 1969/12/31 17:00 Group: Webmasters Registered Users FAQ Admins Stats Admin Posts: 298 Level : 16; EXP : 14 HP : 0 / 378 MP : 99 / 48005	Hi, so I have to correct myself, it works for me with HSpiceS and SpectreS, but not with Spectre. I get the same output as you. Here an excerpt from the HSpice manual: `The ground node must be indicated by either the number 0, the name GND, or !GND.` So one more workaround would be use SpectreS and to run Spectre in Spice compatibility mode. Depending on how important Spectre mode is to you, this may or may not be an alternative. Finally, you could open the master of the nmos symbol and try changing the bulk node from "gnd!" to "0". I am just speculating, but that might also work. In HSpice (and I assume all of Spice) the nodes 0 and gnd! are equivalent. From your results it seems the same is true for Spectre, since you get the same simulation results. On the other hand, I did a global search on the Spectre manual and couldn't find a statement that would back that assumption up. In my opinion, it is always best to use 4-terminal devices. May be more inconvenient, but it also "protects" the user from any behind-the-scene magic that may or may not work. I believe the NCSU kit was designed with a Spice flow in mind and may have never really been validated against a Spectre flow. Johannes Posted on: 2006/2/2 15:49

	Re: A possible bug in the NCSU CDK	#5
Quite a regular Joined: 2005/9/27 10:52 From Columbia, SC Group: Registered Users Posts: 36 Level : 4; EXP : 76 HP : 0 / 94 MP : 12 / 2105	Johannes, If gnd! and 0 are equivalent in Spectre then there's no worries. I'll have to look into that. However, when I simulate the netlist from above, Spectre does issue warnings: Simulating `input.scs' on hebe at 9:21:42 AM, Fri Feb 3, 2006. Notice from spectre during topology check. Only one connection to node `I3.gnd!'. Warning from spectre during heuristic topology check. No DC path from node `I3.gnd!' to ground. There's another strange thing the netlister is doing. When I instantiate the inverter shown above into another schematic, check out the corresponding subckt definition. `// Cell name: INV // View name: schematic subckt INV A Z inh_inh_bn M1 (Z A 0 gnd!) ami06N w=3u l=600n as=4.5e-12 ad=4.5e-12 ps=9u pd=9u \ m=1 region=sat M0 (Z A vdd! vdd!) ami06P w=6u l=600n as=9e-12 ad=9e-12 ps=15.0u \ pd=15.0u m=1 region=sat ends INVX1 // End of subcircuit definition` What the heck is inh_inh_bn and why is it a port on the subckt? I think the answer has to do with the above bulk node problem (hence the "_bn"), but obviously this isn't a real port and it is not assigned a net when the subcircuit is instanced, as shown later in the same netlist file. `I3 (inv_in inv_out 0) INV` Weird... Thanks for all your help, Johannes. -Jason Posted on: 2006/2/3 7:28

	Re: A possible bug in the NCSU CDK	#6
Moderator Joined: 1969/12/31 17:00 Group: Webmasters Registered Users FAQ Admins Stats Admin Posts: 298 Level : 16; EXP : 14 HP : 0 / 378 MP : 99 / 48005	Hi, I was playing around with this some more, but couldn't really find anything conclusive. I see the same hierarchical netlist you see, and despite the warning message the simulation results seem okay. What we are seeing is the "inherited connections flow" in action. As I understand it, it goes something like this: The bulk node on the nmos is called "bn". They define a net expression "inh_gn", in wich they give the node "bn" a default value of "gnd!". But since its a net expression, the user can locally change it to a different value. In order to carry that expression onto the toplevel, spectre adds the bulk net to the subckt interface. But I'm not sure how one would actually go about using that pin on the toplevel. I was able to change the bulk node locally for one nmos from "gnd!" to "0" in its properties and it was reflected in the netlist. But when I tried to change the default value of the net expression in the spectre view of "nmos" it wouldn't accept "0", and refused to recognize it as a global net. It suggested using "0!', which doesn't make much sense either. If you want to, you can open the properties of "bn*" in the spectre symbol and see the definition of the "inh_bn" net expression. This is about as much as I understand. Inherited connections are usually used for the supply pins of circuit blocks. Those are pretty straight forward to use. But I don't quite understand them when they are used for the pins of a device. Johannes Posted on: 2006/2/3 9:53

	Re: A possible bug in the NCSU CDK	#7
Quite a regular Joined: 2005/9/27 10:52 From Columbia, SC Group: Registered Users Posts: 36 Level : 4; EXP : 76 HP : 0 / 94 MP : 12 / 2105	Johannes, I understand. Thanks for looking into that for me. Actually I was wrong in my previous post. When the inverter is instanced, the inh_inh_bn port is being assigned to 0, but this port isn't actually assigned to the bulk node in the internal NMOS (it uses gnd!). It would be fine if the netlister used the inh_inh_bn port as the bulk connection on the NMOS. For example: `M1 (Z A 0 inh_inh_bn) ami06N w=3u l=600n as=4.5e-12 ad=4.5e-12 ps=9u pd=9u \ m=1 region=sat` It's also strange that the subckt only has a port for the NMOS's bulk terminal and not the PMOS's. There's got to be a way to fix this, but if the simulation results are okay with the "floating" NMOS bulk node, I guess it's not something that we should worry about. Thanks again, -Jason Posted on: 2006/2/3 10:34

	Re: A possible bug in the NCSU CDK	#8
Moderator Joined: 1969/12/31 17:00 Group: Webmasters Registered Users FAQ Admins Stats Admin Posts: 298 Level : 16; EXP : 14 HP : 0 / 378 MP : 99 / 48005	Hi, I believe this doesn't happen for vdd! because vdd! is defined as a global net. So it would be interesting to see what happens when gnd! is defined as a global, e.g. with an include file. That might also be a good work around. Johannes Posted on: 2006/2/3 15:38

Top

Previous Topic

Next Topic

You cannot start a new topic.

You can view topic.

You cannot reply to posts.

You cannot edit your posts.

You cannot delete your posts.

You cannot add new polls.

You cannot vote in polls.

You cannot attach files to posts.

You cannot post without approval.