Most efficient db function to move all shapes in a design?

Perhaps try leMoveCellViewOrigin() ? I think that was around in IC5141. Hope it helps.
Lawrence.

Thanks Lawrence.
I am working on a mask reticle view with flat data and thought that working non-graphically with the Database Access functions would be more efficient than working in the layout editor. Non-graphically, I believe some of the functions are taking 15+ minutes to complete. lehiMoveOrigin() will certainly be convenient. I just don't know if working graphically is more efficient. For sure there are more graphics session functions.
- James

You can use leMoveCellViewOrigin(cv x:y) without having to open the database in an editor window. You can just use:

cv=dbOpenCellViewByType(lib cell view "maskLayout" "a")
leMoveCellViewOrigin(cv x:y)

and it will work fine.

Andrew.

Sorry, I thought the le and lehi functions in general would not work in nograph mode.
Evidently it is just the functions that require a graphics window that won't work.
That helps for sure.

I have found that working in no graph mode MAY be slower than working in graphics mode when dealing with millions of flat shapes, but need some more help to know of what I am trying to do is simply going to be time intensive - hours of computing time, if lucky enough not to exceed available memory….which has happened already in no graph mode.

Is there any advantage to using one set of functions dependent on graphics vs. no graphics for this type of data intensive processing?
My specific task is to select a set of flat shapes from a layout of flat shapes, make a new cell view with the selected set, and define its origin at a point within the selection bounding box area.

There are many ways to do this, but the challenge has been the number of shapes to deal with, and hence the efficiency aspect of the thread title.

Making an assumption that working in no graph mode would be more efficient than graphics mode, I have tried deleting shapes using dbGetOverlaps() and working with what is left, but this seems to have been the worst approach.

I have tried using leMakeCell() in no graph mode, passing it a list of shapes found by dbGetOverlaps(), and a new origin point, and though it has to do less processing, I killed it after watching the screen for 2 hours.

Finally, I am stuck trying to figure out how to work in graphics mode, scripting the use of the leHiMakeCell() form.
I'm trying to use the form because in graphics mode, getting a selection set of shapes seems to take much less time than non-graphically.
The form then takes the selection set to create the new cell.
essentially:
(create win, open cell view into win)
geSelectArea(<args>) ; selects shapes
leHiMakeCell() ; opens form
form=hiGetCurrentForm() ; does not consistently get the form…it has actually worked only once
form~>cellName~>value="new cell name"
hiFormDone(form)
dbClose(cell view)

Almost every time I try this, the "form" variable does not get the form ID of the leHiMakeCell() form.
I don't know if it is because the geSelectArea() function is not done when the form is called, or if there is some other way to put values into the form.

There really should be no significant difference between nograph and normal graphical mode (other than any delay caused by the X server actually having to draw and display the shapes). When you run -nograph mode, Virtuoso (icfb) starts (in IC5141) a null X server (Xndx) which is used as the display for the session. This means it still does all the graphical operations (if you're calling it in a graphical mode) - it's just that the X traffic goes to this null display instead.

However, running dbOpenCellViewByType and leMakeCell should not generate any graphical output - I don't believe there are any dialog boxes raised by leMakeCell - it outputs warnings, but no dialog boxes (dialog boxes can be a problem for no graph sessions because you can't see them and so obviously can't click on them).

I see no benefit in trying to automate the UI this way, because all that happens is that the graphical version of the command, leHiMakeCell, collects data from the selected objects (obviously you can't do selection unless there's a window of some sort, which you can do in nograph, but just can't see), the options from the form, and then calls leMakeCell. So if you call leMakeCell with the same arguments that are called from the UI, it should have the same behaviour without all that tedious mucking about with forms.

The problem you almost certainly have is that the code that launches the form will block and so it doesn't get to the next line; you typically have to workaround this using hiRegTimer (or hiEnqueueCmd in later versions), but as I said, this is an unnecessarily complication. I'd try to figure out what's different in the settings you're passing to leMakeCell from those when you use the form.

This might be easier solved by talking to somebody in customer support who can take a look at precisely what you're doing.

Regards,

Andrew.

Hi,

Here's another idea to try: create the new cellview yourself (dbOpenCellViewByType()) and then either move the figures (dbMoveFig()) or copy them (dbCopyFig()) with the appropriate transform (if any) so that they end up at the right place in the new cellview.  Another thing to try is to reduce the sets of shapes into batches, e.g. call geSelectFig() multiple times, or select/identify the shapes another way (for example, based on the layer-purpose pair that they are on?) - sometimes the selection operation alone can take a long time if dealing with lots of shapes, and with SKILL you don't necessarily need to 'select' them, just obtain their dbId's. I would expect the lower-level functions (e.g. "db" prefix rather than "le" prefix) to be faster and/or more efficient than the higher level functions.

Hopefully this might help you?

Regards,

Lawrence.

Thank you both for your comments and insights.
I tried several test cases before replying.
Both -nograph and graphics mode selection by area and leMakeCell() functions work - using small area test cases of the same master design.

But working with over 4 million shapes in the selection set, -nograph mode seems hopeless.
I let it try to complete for 5 hours just to see if I could say it took a specific amount of time before simply killing it.
In contrast, graphics mode completes the same selection and leMakeCell() in less than 10 minutes.

The only difference between the 2 modes is the use of dbGetOverlaps() as the first argument to leMakeCell() in -nograph mode, and the use of geSelectArea() and geGetSelectedSet() as the first argument to leMakeCell() in graphics mode.
ie:
<-nograph mode>
leMakeCell(dbGetOverlaps(cv bbox) libName cellName "layout" t list(xCoord yCoord))
<graphics mode>
geSelectArea(win bbox)
leMakeCell(geGetSelectedSet() libName cellName "layout" t list(xCoord yCoord))

dbGetOverlaps() generates a list.
geSelectArea() does not, so geGetSelectedSet() is used to generate the list in graphics mode.

I did try the dbCopyFig() option in -nograph mode instead of going directly to leMakeCell(), but it is dependent on the same use of dbGetOverlaps() to generate an input list to loop through.
eg:
shape_list=dbGetOverlaps(cv bbox)
foreach(shape shape_list dbCopyFig(shape new_cv offset:offsetY))

That -nograph sessions can't seem to complete what is essentially the same task because of the size of the operating list is not at all what I expected.
I do ask customer support for help as well, but ic5141 is not officially supported anymore.

I doubt this is anything to do with -nograph, but what rather to do with what you're getting back from dbGetOverlaps compared with the selection. For a start, dbGetOverlaps will find any shapes who have bounding boxes that overlap the area, including those on non-selectable layers. geSelectArea() will find the shapes completely within the selection area.

I'd debug this by running graphically and seeing what the difference is between using dbGetOverlaps and geSelectArea. That might reveal the root of your problem. If it's dbGetOverlaps taking too long to return, that might be hard to do anything about.

I think customer support should be able to help you here, because this is just guidance on how to implement something with large number of shapes, rather than being version-specific. Yes, you're using IC5141, but the principles should be the same if it was a supported version.

That said, I'm not sure what you're trying to achieve - it may be that this is an application for which CDB is not well suited - but that's something you can explain more to customer support.

Kind Regards,

Andrew.

Although IC5141 is not officially supported, it also sounds like nothing you are trying to do is necessarily specific to that version, the SKILL side of things is probably more-or-less the same.

I don't know how close your example code is to what you are really doing, but if you are simply using dbGetOverlaps() or geSelectArea() to select any and all shapes (as your sample code suggests) within a certain bounding box, maybe an alternative approach would be to process from the shapes and look to see if their bbox is inside or outside the target bbox? This might also allow you to break down the task into more manageable chunks, for example going through shapes on various LPPs one LPP at a time, rather than all together. So you could start from cv~>shapes or you can look at cv~>lpps, and then process shapes on each LP object that has shapes in the cellview (layer-purpose pair objects can exist for shapes that are at a different level of hierarchy but no shapes on that LPP are in the current cellview). I think that Andrew has shared code on this forum for detecting if a bbox is within a bbox, to save you writing it.

I hope the above helps!

Best regards,

Lawrence.