Forum Replies Created
-
Posts
-
Sorry, that should read
obj = objs.first()
About loading in this function so it's callable, I need to do a bit more work, as currently only stuff you type into the message window gets added to the Python globals dictionary. Stuff loaded via the 'run Script' or -script cmd line option gets evaluated in isolation, which is not very helpful…
OK in the latest 4.1.2 build there is support for adding an object to the selected set. So you can do e.g.
# Following routine selects all instances that connect to the net
def selInstsOfNet(netname) :
cv = getEditCellView()
nt = cv.dbFindNetByName(netname)
instPins = nt.getInstPins()
ip = instPins.first()
while ip :
i = ip.getInst()
addSelected(i)
ip = instPins.next()or you could try:
# Following routine selects all instances connected to a selected net
def selInsts() :
objs = getSelectedSet()
obj = obj.first()
nt = obj.getNet()
instPins = nt.getInstPins()
ip = instPins.first()
while ip :
i = ip.getInst()
addSelected(i)
ip = instPins.next()Well you can almost do it in Python… I'll need to add the capability to add to the selected set from a Python command, as that bit's missing at the moment.
Version 4.1.1 is released and downloadable for Windows/Linux32/Linux64 (Solaris to follow in a few days).
The main change is the new database code for region query is enabled, and has been tested and seems to be stable now after a few fixes related to deletion etc. The main advantage is (1) better speed and (2) reduced memory usage.
There are several other small bugfixes, see the change log in the documentation for details.
Also, the Windows build is moving to VC++ 2008 (VC9). Initial tests show that raw code performance from this compiler are 5-10% slower than VC++ 2003 (VC7), however VC9 has a lot less bugs and better language support, and a bit of careful code profiling analysis can make up for the initial apparent performance losses. If you see any problems, please let us know.
There is no equivalent 'cut and paste' for copying objects in one cell to another. What you could do is use the 'Edit->Hierarchy->Create' to create a new cell from some existing shapes in a cell. Place this cell in your destination cell and (if required) flatten them.
In theory some sort of drag and drop approach could be implemented but the use model would need to be thought out carefully. I'd welcome comments / views.
Currently the way it works is that LEF BUSBITCHARS is set on the library the LEF is imported into. So if you import two LEF files with different BUSITCHARS into the same library, the last one imported sets the BUSBITCHARS for the library.
Hence the problem you're seeing – the second LEF is setting BUSBITCHARS to <>, so when it is reading the DEF with BUSBITCHARS as [], it will replace A[1] with A<1> etc.
Version 4.0.45 uses a new spatial data structure, however this has found to be unstable by several people. As of today this has been disabled and the code rolled back to the previous version. So if you've been experiencing problems with 4.0.45, download today's build please. Apologies for the problem.
Under what circumstances is this occurring? Can you provide a log file?
Also try setting the env var 'GLADE_NO_EXCEPTION_HANDLER' to NO, this may provide amore info on the crash.
Ah the ui.py in the linux distribution was out of date. I rebuilt it last night, it should work fine now.
Sorry, don't see the attached logfile?
Does the script run OK if run from glade rather than as a command line option?
You can do this:
1) Create pins using the Edit->Create Pins from Labels cmd. This assumes you have text labels in your GDS where you want pins.
2) Copy the cell to a new cellview, with the view type 'abstract'
3) Output the LEF.
This is rather simplistic, to do a better job you will need to write an extraction rules file to extract connectivity using geomLabel() to create pins, also copy blockage shapes to the boundary purpose so they get output in the lef OBS section.
The latest version features support for importing Laker .dsp / .tf files. Currently there are a few limitations:
– does not handle tfDisplayGroup, only explicit layer declarations in tfLayoutLayerTable. This limitation will be removed in a future release.
– only reads dbuPerUU from tfLayoutSystemUnit.
– reads tfLayoutLayerTable and tfStreamIoTable, all other techfile data ignored.
