Forum Replies Created
-
Posts
-
Sorry there is a problem with the data – your inv1 schematic has no devices or pins. I suspect you copied the original which references ones from (maybe) the example lib?
I can try and re-create it but there's no way of being sure that the connectivity is the same, particularly in the case of e.g. global nets.
Edit: I am guessing, but from the CDL files you included,
1. The inv1 schematic netlist has globals vdd!/gnd! but the mos devices connect to nets VDD/GND. THis suggests you renamed the power/ground pin names in the schematic perhaps? But did not change the global net names when exporting the netlist.
2. inv2 schematic netlist now keeps the VDD/GND net names within the subckt inv1, yet with the globals vdd!/gnd! this means the nets will get flattenned to /X1/GND etc.
The mismatched device properties is another issue. The CDL flattener was not writing *.SCALE METER to the flattened netlist, so Gemini thinks the units are microns. So a device of say L=2u is interpreted as L=2.0e-12 and hence gives a mismatch. This will be fixed in 4.2.25. In the meantime, you can manually edit the inv2.cdl_flat netlist and add the *.SCALE METER and then it will compare properties OK.
Yes that's correct. Gemini expects flat netlists, so in the run LVS dialog you need to specify if the netlist (from the schematic) is hierarchical, and if so the top cell name and any global nets.
It will then call the CDL netlist flattener which creates a flat netlist to pass to Gemini.Yes that's a bug, the pin direction setting in the query dialog does not update the pin direction.
It'll be fixed in 4.2.25.
The setting is in the Display Options dialog in 'Object Settings' in the groupbox Instance Names. It can be either 'Preserve' or 'Force Spice compatible'. In the latter case, during Check (and also when creating an instance) it will look at the 'type' property if present, and if so change the prefix from e.g. I0 to M0 for a mos device.
Yes there is an option for this, I do not have a PC to hand at the moment but think it's in the display options miscellaneous dialog. Also note that device symbols need the 'use' property set.
The only way to do this currently is to create a wire label for the net you wish to (re)name, then run Check. Selecting and querying and changing the net name in the query dialog won't run connectivity extraction (it shouldn't crash – that sounds like a bug).
Sorry, that was a typo, should be 'spurious' label.
There is a small label with name QB on the pin drawing layer. If you set only the pin drawing layer selectable, and select all (ctrl+a), you should be able to find it and delete it.
Quote:Let me confirm the relation of pin and pin-shape…In this symbol I created, the property for input pin has "pin shapes" value of 0, and in the cell property, the value of "Num pin" is 4 (actual total number of inputs/output).
The shape you have selected is part of a net, but not of a pin.
Quote:https://gyazo.com/e4d76b652cb1726c8e55ec423ac7b06cI'm still confusing what "pin shape" value in net's property mean…
This shows the cellView has 4 pins / 4 nets which is a sure sign something is wrong, as you would expect 3 of each for a cell with 2 inputs and 1 output.
Quote:(addition) after CheckCellview, the "pin shape" became 1… Is this the correct operation of Glade? (I'll have to CheckCellview to keep consistency of all the properties?)Check->CellView does try and clean up the symbol connectivity. I have enhanced it further in 4.5.24 to try and fix more potential errors. I'd always advise running it before saving the cell.
Quote:Can you tell me why (how) the pin with pin-shapes>1? I didn't intend to create it in this case. In the conventional usage, by creating the net with net name specified, does it create a net with pin, Pin-shape=1, and instPins=0? By the correct net/pin creation procedure, the property for the whole symbol will have "Num Insts"=0, "Num Nets"="Num Pins"=actual number of nets/pins, "Num Shapes" is the number of line, ellipse, etc. including net in th e symbol?
I think I'm still confusing the relation of inst/pin&net/shape…It means you have a logical pin, which has more than one shape associated with it.
Num nets / Num pins refers to the logical net/pin count. Num shapes refers to the physical shape count.The set of shapes consists of a smaller subset of shapes with a net, and an even smaller set within this of shapes with a net and a pin.
Quote:Let me report the similar problems:Please download the example library files:
https://www.dropbox.com/s/1773urq2bo9m0bm/test2.zip?dl=0There are two cells with symbols; inv1 and dff. They have two/four nets and pins, respectively, and CheckCellview seem to be OK (no 'invisible' nets exist).
I've created a sche_test schematic with the symbols, but by CheckCellview crashes Glade.The cell 'dff symbol' is OK, except the label '[@instName]' is on the 'pin drawing' layer. It should be on another layer (doesn't really matter which, but don't use the layers 'pin', 'wire'). Normally an instance label is created on layer 'annotate drawing7'. Also the label should be of type 'NLPLabel',
There also was a label 'QB' on the pin drawing layer, and a label on the 'NWL' layer.Selecting all and stepping through them using the Query dialog allows to you see these, and delete them or change layer as required.
It didn't crash for me, but gave some errors, after making the changes there were errors about floating pins, which are correct as there are unconnected pins in the schematic.
Quote:Additional memo: I had a mistake in dff symbol; the [@instName] was drawn by Net layer. I've deleted it, and then created a text as instance label. However, the sche_test schematic's CheckCellview still results in crash.
Here is the library data with modification above.
https://www.dropbox.com/s/wqmwrngxzcjtmb2/test3.zip?dl=0Can you give me advise?
In this case you have corrected the instName label in the dff, but the sourious label still remains. Even so I did not get a crash in 4.5.24.
I'll add in a check for the net name during creating a pin, and error out if an invalid name (or no name) is specified.
The error you mention is coming from when a schematic is loaded and it's trying to re-create the connectivity. All I can really say is it's trying to create instPins at this stage, and the function is being called with an invalid net. I'm not sure the data is recoverable.
Its possible to remove the net using python, although it depends whether the net really has an empty string as a name, or something else… this may or may not work:
cv = getEditCellView()
net = cv.dbFindNetByName("")
print netif you have a valid net, then:
cv.dbDeleteObj(net)
will delete it… Else Check->Check CellView should get rid of it if it has no pins.
1. 'Set object as pin' will only create a pin if the net name changes, i.e. the shape was already part of a net, and the net name was different to the one in the 'Net Name' field.
I'll change this so it detects if the shape is not a pin shape of the specified net, and if so creates a port for the pin/shape.
2. If pin shapes is > 0, the number is the actual number of shapes for the (logical) pin. There can be multiple pin shapes (ports) for a single pin, for example an abstract view as used for LEF generation may have multiple ports.
3. A net may not have shapes associated with it, it can exist in its own right, which may explain this. I have modified the sumbol Check->CellView so that nets with an empty name are deleted.
Hope this helps!
The pin shape should not have instPins – these are created at the next level up in the hierarchy, and used to make the connection between nets at a higher level of hierarchy to pins on the lower level.
In the case of the inv1 you have, the symbol view should have 2 nets (named I and O in your case).
There should be 2 pins also – these like nets have no physical representation. A pin is the connection to a higher level in the hierarchy.Nets can have shapes – so the physical rectangle in the pin layer will have a net that you can see by querying the shape's properties. There can be many shapes to a net, but only one (or no) net to a shape.
A net may or may not have a pin. A pin has to have a net.
Pins can also have shapes (or ports). There can be more than one port per pin.
If you select a pin shape and query it, you should see 'Pin Shapes' set to 1, 'Inst pins' set to 0, and a net name/pin name (which are normally the same).
Clicking on the 'Set object as pin?' box will set the shape as a pin shape and create a pin if there is not one already.
You can't select a pin or net directly, as it is a logical rather than physical entity – you can only
I'd have to see the data to really know what's going on.
The warning message is basically saying that when trying to create an instPin for the inv1 instance in the schematic, it's lokking for pin I / pin O in the master (i.e. the symbol view) and is not finding it.
If you edit the symbol view, with nothing selected use the 'q' bindkey / query properties to see the cellView attributes. There should be 2 nets / 2 pins shapes. If you select a pin shape, you should see the net name (e.g. I) and there should be a pin for this shape. It sounds like you have pin shapes, and possibly nets, but no logical pins.
