[Keith]

I checked the line number of the error and basically it was trying to open a file in write mode. So probably a permissions problem. I'll make the error message a bit more descriptive.

[Keith]

'file0000.dat' is the first derived layer in your rules file. So for example in the distribution extract.py, this corresponds to the derived layer 'nwell'. Glade will create this file in the directory that the .exe was invoked in. It will also try and read the file from the same location.

[Keith]

You'll have to ask for an ASCII version. The binary format is probably compiled skill code which is only readable by cadence.

[Keith]

Hmm, you're correct. The self-intersecting polygon check that is performed whenever a polygon edge is stretched is failing for the chopped polygon case that has two abutting edges. This will get fixed in the next version.

[Keith]

The docs come with the app (see the Help->Contents… menu).

Some parts of the tool chain you mention are there. Others are being worked on…

[Keith]

This sounds like an OpenGL bug. You might want to check if you have the latest drivers for your graphics card?

[Keith]

Are you running on Windows with OpenGL or not? To find out, check in the logfile – if you see e.g. "OpenGL Version" then you are running OpenGL. Same goes for Linux.

If the attachment does not work try emailing it to support@peardrop.co.uk.

thanks!

[Keith]

Do you mean any angle rotations? That would be possible for some types of object e.g. polygons / paths / rectangles (which would get converted to polygons).

Rotating instances/arrays by anything other than 90 degrees is currently not possible without increasing the memory footprint.

[Keith]

This will be fixed in 4.1.33, to be released later today.

[Keith]

You can mail the example that fails to support@peardrop.co.uk. It works on a simple example I tested it on, but there may be issues I am unaware of.

[Keith]

I've made a few changes and its now working as expected from Python. An example as follows:

Code:

# Get the edit cellView
cv=getEditCellView()
#
# Define some search rectangle
searchRect = Rect(40000,300000,80000,400000)
#
# Set up a list to receive the objects found
objlist = dbHierObjList()
#
# Do the search on some layer
cv.dbGetHierOverlaps(objlist, searchRect, 9)
#
# Iterate thru the list
objpair = objlist.first()
while objpair :
obj = objpair.first()
trans = objpair.second()
print "Object ", obj.objName(), " with transform ", trans.name()
print "Coords (", obj.getXLo(), ",", obj.getYLo(), ") (", obj.getXHi(), ",", obj.getYHi(), ")"
objpair = objlist.next()

[Keith]

Let me check and get back to you. It may need a few changes to the implementation to get dbGetHierOverlaps working with Python in a usable fashion.

[Keith]

dbGetHierOverlaps changed, and the documentation has not yet been updated. Currently it is:

cv.dbGetHierOverlaps(dbObjList<dbHierObj> *list , Rect
box, int layer, int allLayers = 0, int level = 99)

Searches the are given by box for
any objects whose bounding boxes overlap the area. If allLayers is 0, only the shapes on the specified layer are returned. If allLayers is 1, shapes on all layers are searched. The
search is carried out hierarchically up to level
levels deep.

A dbHierObj is just a
pair<dbObj *, dbTransform>
i.e. the object itself and the transform of the object relative to the top
level.

[Keith]

Version 4.1.31 is now up and on the server after a problem yesterday with a partially copied file for the Win32 build.

Various bugfixes have been made, mainly in the edgefile code, which caused problems with drc/extraction scripts.

[Keith]

OK I have found a potential issue in the geometry processing code which may cause a crash. Please try version 4.1.31 which has the fix.

[Author]

Posts