Forum Replies Created
-
Posts
-
Hi Paco,
I will have to look at that. Normaly there is a property called 'type' on extracted device instances which specifies their type to the netlister. So for a capacitor you would have the property 'type' set to 'cap'.
regards
Keith
Hi Paco,
I have put a version of 4.3.53 for win32/win64 only on the website (index page not yet changed). This has :
– Export CDL bug fixed
– Gemini has permutable capacitors and resistors. Also inductors and diodes (diodes are not permutable). CDL netlist 'm factor' is supported (currently just multiplies effective with of device by m factor).
This makes your example circuit verify correctly. Obviously other things need doing as mentioned i.e. $permute, and considering device model name in matching.
regards
Keith
Hi Paco,
The idea is to use the model name to distinguish devices. Similar to matching L and W properties, the model name needs adding to the properties and it should be an error if they do not match.
Right now the version of Gemini does support R, C, and Q (bipolar) types in LVS. Inductors etc. could be easily added.
Just looking at the code, MOS devices have different terminal classes for each pin (D=0 G=3 S=1 B=2) so I'm not sure how you can permute D/S/B on mos devices as previously mentioned.
I can change resistors and capacitors to make both terminal classes 0 in the interim.
What I am thinking of for the longer term is to have a property on devices called $permute, e.g.
$permute="0,1"
for a capacitor means do not allow permuting its pins. You could then set this property on either instance masters or individual instances (which would override any set on the instance master). Less messy than reading seperate permute files.
What do you think?
regards
keith
Hi Paco,
There are several problems:
1. Reading the documentation, if you define a new usertype, it has to replace the existing device type e.g. 'M' or 'C' at the start of the line.
2. It has to be instantiated e.g.
ZC vin vout ; <attributes>
Currently attributes are not read, as the docs declare.
I suspect that a complete rewrite of the user types code will be needed, or maybe it will be easier to read some kind of pin permute file for devices.
regards
Keith
Hi Paco,
If you have an example of two spice netlists which do not match without using permutation rules, and use the keyword
*DEFINE …
(which will be treated as a comment by normal spice parsers) to define the permutation in SIM format, then I can try it out.
I'm not so hopeful though as looking at the code it appears there are no calls to 'UserDefLine' which is the function to enter user-defined devices. As far as I can see, at least in the version of Gemini I have, this has been removed at some point.
regards
Keith
Hi Paco,
I do not convert from Spice/CDL to either Gemini format or SIM format. Rather, I read Spice/CDL directly using something very similar to the orginal SIM reading code.
I'll have to take a longer look at this, hopefully at the weekend. There's something I am missing as I can't see why the capacitor terminal order should be cared about (although maybe you DO wish to care about it), same goes for MOS source/drains, normally they are interchangeable, and in fact the extractor just attaches the first diffusion shape it finds to the MOS source terminal, the second to the drain terminal.
regards
Keith
Hi Paco,
As far as I can see from the docs and code, the SIM format DEFINE command is to define user specific devices. The spice format reader (-S option as you deduce) could read a slightly different syntax e.g. *define as the code is a copy of the SIM format reader, with minor changes for Spice syntax.
But I don't quite understand the problem. Aren't e.g. the two capacitor terminals already treated as equivalent? How does defining a new device type (I think this was meant for logic gates initially) help?
You are welcome to the gemini source if you want to look deeper – it's public domain after all; I've just done a few modifications to e.g. read Spice formats and output errors in a format suitable for Glade (-g option).
regards
Keith
Hi Paco,
I'll look into this. I may not be able to fix it before the weekend as am very busy at the moment, but I'll try.
regards
keith
Hi Paco,
Odd, I tested it earlier and it was working… what options are you using for the CDL export?
regards
Keith
I found the problem, a global search and replace had missed 3 lines of code where colour was being set – drawing the cursor, drawing the ruler and drawing moving instances. I've fixed it and will release 4.2.52 with this and the fix for export CDL today.
Bother.
I had changed the way colours are handled in the techfile – rather than use QRgba, use QColour instead, in order to get transparency to work correctly with the non-OpenGL engine.
It looks like this has some problems on the OpenGL version. Apologies, I'll get this fixed asap.
regards
Keith
Hi Paco,
I looked into it and the cellView's bounding box (use q bindkey to show it) has a maximum y value of 201.750um. However the N well max y is 200.750um. Hence the geomAndNot to form pwell produces a sliver between the top of the nwell and the top of the bbox correctly, and of course this is not connected to anything, hence the 'floating' node.
I'm not sure how the cell was created – via reading gds2 or manually – but somehow the bounding box is slightly bigger than the actual data.
you should be able to reset it by:
cv = getEditCellView
cv.updateBbox()regards
Keith
