How to modify or manipulate bBox in layout (Virtuoso, IC 5141 USR4)

 Never face such problem but dbComputeBBoxNoNLP or dbComputeBBox should work.

Hi Quek,

That is exactly what I mean! Thank you for your advise. I also know your solution. This usually helps but that is unsatisfying!

If I just know the reason why that happens. Perhaps I could find the way to solve it in a proper way!

Hi Dennis

I think it is just a small bug in the layout editor. Actually I don't recall seeing this problem in the current version (5141.500.6.140) which I am using. I think your next best alternative is to upgrade to the latest release. : )

Best regards
Quek

Hi Dennis

One correction to my previous post. It is not possible to modify a cellview's bbox through ~> operator but it is possible to do it using dbComputeBBox cmd as suggested by babji. Maybe you can also try this:

a. Open a layout that has this problem
b. Enter the following in ciw:

dbComputeBBox(geGetWindowCellView())

Hope that this works. : )

Best regards
Quek

Hi Quek,

I will speak with Cadence contact person in my department. Perhaps he can update to an actuall version.

And I will try the suggestion of babji.

 Thanks!

 Best regards, Dennis

We have seen this problem as well. We see the problem primarily when we are working with mosaics and using edit-in-place. We opened a ticket many years ago on this, but it was not fixed in any of the 5.1.41 releases. The case we saw was when we edit-in-place into a mosaic and make some edits, the bBox will grow to the furthest extent of the edits, even if no data remains there when the edit is done. To test this out, you can EIP into a mosaic at least 2 levels down in your hierarchy. Do your EIP into one of the outside rows or columns. Move a shape a good distance outside of the current bBox and then move it back. Save the cell and pop up one level. You'll see that the cell extents remain too large. The current cell will also be affected by those cell extents. There may be other things that cause this extents bug but I am not aware of them.

We did find an acceptable fix for this problem. If you draw a rectangle larger than everything in the current cell and then delete it and save the cell, the extents will be fixed. We put this "Fix Cell Extents" procedure into a menu and it fixes the problem for us.

Derek

Hello Derek,

thank you for your reply! If it is possible, can you post this procedure here?

Kind regards, Dennis

I hope this helps. We've refined this to do not just create a large rectangle and delete it, although I think that still works in most cases.

Derek 

procedure(myFixCellBBox(@optional (cv geGetEditCellView()) (quiet nil))
  let((bbox akey textDisplays)
    bbox = cv~>bBox
    ; lowerLeft
    akey = dbCreateRect(cv leGetEntryLayer() list(xCoord(lowerLeft(bbox))-5.0:
      yCoord(lowerLeft(bbox))-5.0 lowerLeft(bbox)))
    when(akey dbDeleteObject(akey) ) ; when
    ; upperRight
    akey = dbCreateRect(cv leGetEntryLayer() list(xCoord(upperRight(bbox))+5.0:
      yCoord(upperRight(bbox))+5.0 upperRight(bbox)))
    when(akey dbDeleteObject(akey) ) ; when
    ;Fix textDisplay bounding boxes
    textDisplays = setof(x cv~>shapes x~>objType=="textDisplay")
    foreach(td textDisplays
        schSetTextDisplayBBox(td nil) ;This also works in layout
    )
    dbComputeBBox(cv)
    akey = dbCreateRect(cv leGetEntryLayer() cv~>bBox)
    when(akey dbDeleteObject(akey) ) ; when
    unless(quiet
        printf("Now execute \"Fit All\" and see if your cell extents are fixed\n")
    )
    t
  ) ; let
)

Thanks a lot once more!!