[Keith]

Since the change to having dbuPerUU as an attribute of a cellView, inheriting from the library, rather than just using the library dbuPerUU attribute, it looks like creating a cellView was ignoring the library value.

I've made some changes in 4.6.17 and it will scale the dbuPerU as you expect. The new version should be available in the next day or two.

[Keith]

I've rebuilt the RHEL6 / CentOS6 build and it seems to be working OK now and not hanging.

The version has been uploaded to the website as of 13:00BST today.

[Keith]

When you say 'not able to open', what exactly do you mean? What error message, if any, is shown in the spice message log / spice.log file?

What platform (Windows32/64, Linux, Mac etc) ?

As for importing EDIF, there is an EDIF in translator in progress at the moment. So far I've only tried Cadence EDIF format. Do you have an example you can send?

[Keith]

Without some example data it's hard to say, but the first thing to check is the technology file is seeing the MET1 minWidth. You can check this by hovering the cursor over the MET1 layer in the LSW, you will see various layer attributes, one of them is minWidth.

Note that routing data is imported into the layer purpose "net", not "drawing".

To write out GDS, you can do this as long as you have GDS layer mapping set up for the layer(s) you wish to export. So your Glade techfile should include all the purposes used for LEF/DEF e.g. MET1 drawing, MET1 net, MET1 pin, MET1 boundary. And these layer/purposes need a GDS layer number/datatype defined.

If you want to swap the abstract views for layout views before exporting the GDS, make sure you have imported them into the library along with the abstract views, then use the Floorplan -> Replace Views command to swap the abstract view for the layout view.

[Keith]

Hmm interesting. I'm running 10.11.6 (El Capitan) and don't see that issue. I can try and upate my OS and see if that makes a difference.

Are you displaying in tab style or MDI window style? Is this a recent version (4.6.8 is most recent)?

[Keith]

geomErase() does not set the cellView edited, as the normal usage is at top level when running DRC to erase dummy layers used for e.g. debugging. This could be changed, though.

To erase ALL objects on a specific layer, you can do this in python:

Code:

lib = cv.lib()
tech = lib.tech()
layer = tech.getLayerNum("layerName", "layerPurpose")
lpp = cv.getLpp(layer)
cv.deleteLpp(lpp)

[Keith]

Yes this is an issue where child cells are from a different lib. This should have been fixed a while back, but it looks like the code was not checked in.

The fix will be in 4.6.8.

[Keith]

All input data is flattened by geomGetShapes() to the edgefiles used by subsequent geom.. commands, since this is normally what you want to do for DRC etc.

What is it you are trying to achieve? If you just want to delete objects, you could put some python code in your script before geomGetShapes() to manipulate data in the hierarchy.

[Keith]

The server for the web pages and forum has been moved, hopefully this will be transparent to users now. Apologies for the downtime today.

[Keith]

Thanks to an excellent testcase provided by one user, I've been able to fix several longstanding bugs in the geometry code, particularly in handling any-angle polygons etc. Fixes are in 4.6.7.

THere may be other issues not uncovered by this example, so if you find one please report it.

[Keith]

Also, about your crash: you should always check that getLibByName returns a valid library. It could be that the library name is invalid, in which case it will return a null pointer and trying to call dbOpenCellView using it will give a seg fault.

[Keith]

The geom… functions are described in the 'verify menu' section of the documentation. Although mainly used for e.g. DRC/extraction, they can be used in any python script. You just have to remember to call geomBegin / geomEnd, which sets up the memory pool for the geometry engine.

To erase all shapes on a layer, there is the geomErase function.

[Keith]

Hi,

Can you give more details on the crash – what platform, what version, do you have the stack trace produced by the crash?

I don't see any issue when I try an example:

Code:

>>> lib = getLibByName("example")
>>> lib
<ui.libraryPtr; proxy of C++ cdb::library instance at _205d261100000000_p_cdb__library>
>>> cv=lib.dbOpenCellView("test", "schematic", 'a')
>>> cv
<ui.cellViewPtr; proxy of C++ cdb::cellView instance at _6015d4fff57f0000_p_cdb__cellView>

[Keith]

Use the Help->Contents menu within the tool, the documentation is not on the web.

[Keith]

The answer depends on what you're trying to do. If you want to find all intersections of one layer to another layer, and generate shapes on a third layer, you can use the boolean operations as described in the documentation section on verification. For example in a python script you could have:

Code:

# initialise the boolean engine
geomBegin(cv)

# set which viewname we want to save to
setExtViewName("layout")

# get the layer geometries.
layer1 = geomGetShapes("layer1", "drawing")
layer2 = geomGetShapes("layer2, "drawing")

# form intersections
layer3 = geomAnd(layer1, layer2)

# save layer back to cellview
saveDerived(layer3, "layer3", "drawing")

geomEnd()

If you want to search for shapes on a layer, then do something on a shape by shape basis, you can use region query. See the documentation 'Programming Glade in Python" for an example.

[Author]

Posts