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

I'm not sure how many times I have to say that -nograph is running the same way as in graphics mode as far as icfb is concerned. The memory allocation is the same. Derek was merely explaining that if you're dealing with very large numbers of shapes, you might be better off pre-allocating memory (using needNCells) for database objects rather than letting it dynamically allocate them in smaller chunks. Otherwise it can spend a lot of time in trying to garbage collect each time it allocates more memory. This is NOTHING to do with it being in graphical or non-graphical mode.

That said, I did a quick experiment in IC5141 and found that if I use this code:

cv=dbOpenCellView("ether" "top" "layout")
;dbOpenHier(cv 32)
cv2=dbOpenCellViewByType("ether" "top" "filtered" "maskLayout" "w")
leYankFigs(cv list((0:0) (2000:0) (2000:2000) (0:2000)) 0)
lePasteFigs(cv2 (0:0))
dbSave(cv2)

(I assume you're remembering to save), then if I do:

icfb -restore yankpaste.il

then it's missing the top level shapes. If I run icfb and then load("yankpaste.il") then it's OK. There's some strange timing issue at startup. In non-graphics mode, it never quite works properly (I didn't extensively test it - and anyway my data isn't really setup to directly replicate what you're doing).

Anyway, I'm not spending time on this if somebody from the customer support team elsewhere in the world is looking at it; I don't want to double up on effort, particularly when it's a Friday night and I want to go home!

Regards,

Andrew.

Thanks for the tip Lawrence.
leYankFigs() and lePasteFigs() works much faster - seconds - graphically.
But I get no results in my new layout when trying Yank and Paste in -nograph mode. I get an empty layout.

Derek, are you thinking that -nograph mode may need special memory allocation, uniquely from graphics mode?

I recall having performance problems in 5.1.41 when dealing with many flat shapes. I was able to get much better results after pre-allocating some memory to help eliminate garbage collection. If I recall correctly, I had to use needNCells on the dbobject. The following command will set aside enough memory to handle 4 million objects before garbage collection. You could also try increasing the number (but you'll need to stay within the memory limits of the tool). Use "top" to see how much memory your icfb or layout process is using before and after this command:
needNCells('dbobject 4M)

You can use gcsummary to see a list of all the object types and how many times garbage collection was run on that object in the last column.

Another possibility is that dbProduceOverlap is more efficient in 5.1.41 than dbGetOverlaps. In 6.1.7, they appear about equal. The doc says this:
Returns a list of all the shapes in a cellview whose bounding boxes overlap the area specified by l_bBox. This function interface is simpler than dbGetOverlaps if you are only interested in finding the overlapping shapes.

Derek

One more thing to try/think about - have you tried the Yank and Paste commands? leYankFigs() (not sure if that's present in IC5141, but leHiYank() should be), and then lePasteFigs()/leHiPaste() - compare these with what you have... Good luck, happy coding :-) - Lawrence.

Thank you both for your responses.
Andrew, I am opening a case to look into the issue I am having with dbGetOverlaps().
I agree, the main issue has to do with the difference in how dbGetOverlaps() and geSelectArea()|geGetSelectedSet() produce their lists.
The difference between -nograph and a graphic session is more about how geSelectArea() is not an option for a -nograph session, and I keep thinking doing this non-graphically simply has to be more efficient.

I am working with a single layer mask reticle view with no hierarchy.
It is a flat design consisting only of shapes, and there are no shapes overlapping the selection bounding box.
I'm selecting die regions of the mask and comparing them with XOR to confirm the mask data in each region is identical.
Using results from the graphic session extractions, I have already confirmed the process works.

Lawrence, given the single layer, shape only, and flat nature of the design data, I don't think there would be any benefit to looping through the shapes within a selection bounding box. I can't cull the potential selection set by layer or object type. They are all the same in that respect. Writing a setoff(shapes cv~>shapes bbox<test>) loop seems like it would not be any more efficient than a predefined function. Is this what you are thinking might work better?

Without getting into the actual code, yes it is identical to the example code - with the understanding that to run it, I have the parent cellview open, and I use looping constructs to define different bbox, new cellnames, and new cell centerpoints for each selection area and leMakeCell().

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.

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.

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.

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.

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.