Library cell instance remembering old subcells

edited May 2015 in General
When a library cell changes in any way, the derivative layouts (layouts that use the library cell) should update. This happens correctly in most cases but not all.

Steps to reproduce the problem:

1. New layout. Save as "TEST_LIB.gds", library name: TEST_LIB. Top cell name: LIB_CELL1. Make two child cells under LIB_CELL1 called LIB_CHILD1 and LIB_CHILD2. Draw some shapes on LIB_CHILD1 and LIB_CHILD2, and save. Close and reopen KLayout.
2. New layout. Save as "derivative.oas". Instance LIB_CELL1 from TEST_LIB. Save. Close the file.
3. Reopen TEST_LIB.gds. At this point you can make several changes to TEST_LIB:

A1: Draw some additional shapes on LIB_CHILD1/2
A2: Delete some shapes from LIB_CHILD1/2
A3: Drag an edge to modify an extant shape on LIB_CHILD1/2
A4: Add another child called LIB_CHILD3 with some shapes inside it, under LIB_CELL1
A5: Add a grandchild cell under LIB_CHILD1 with some shapes inside it, called LIB_GRANDCHILD

B1: Shallow delete LIB_CHILD1. So, LIB_CHILD1 becomes a top-level cell.
B2: Deep delete LIB_CHILD1. So, LIB_CHILD1 disappears entirely.
B3: Rename LIB_CHILD1 to LIB_NEW and make some changes to the shapes inside it.

4. Make one of the above changes. Close TEST_LIB.gds. Close and reopen KLayout. Open derivative.oas to see if the change has propagated.

RESULTS:
All "A" results: The change is correctly shown on derivative.oas.
B1 result: LIB_CHILD1 does not disappear from derivative.oas. This problem often shows up for me when I delete library subcells in order to replace them with other subcells. In that case since the old incorrect subcells do not disappear, they are overlaid with the new subcells.
B2 result: Same.
B3 result: Both the old version of the shapes and the new version of the shapes are shown overlaid. So it's the same as if I deleted LIB_CHILD1 and added a new cell LIB_NEW -- actually both LIB_CHILD1 and LIB_NEW are overlaid, when I actually just want what is in the library which is LIB_NEW.

I don't think this is the desired behavior. Any change, big or small, made to library cells, should propagate to derivative.oas. Do I understand that correctly?

To get around "B" cases, I found you can delete all LIB_CELL1 instances from derivative.oas, then re-instance each one with their original transformations. However this is not feasible if there are thousands of LIB_CELL1 instances each with different transformations, because every single LIB_CELL1 instance must be deleted before re-adding them to the layout -- i.e. you can't replace them one-by-one, first all instances must be purged and then all must be re-added.

Is there a way to refresh the library cell instances without doing this? Perhaps a scripted solution that forces a refresh?

David

Comments

  • edited November -1

    Hi David,

    thanks for pointing that out ... the behaviour is not intended indeed. If you modify LIB_CELL1, it should be updated in the file, no matter what the changes are.

    I'll debug and try to fix that problem.

    Thanks for pointing that out.

    Matthias

  • edited May 2015
    Thanks Matthias,

    Do you have any ideas for short term fixes via Ruby or otherwise? Such as somehow forcing a refresh of the library instances?

    David
  • edited November -1

    Hi David,

    I was able to fix the issue, but in all cases, the deleted cells will appear as new top cells after loading, because they exist in the original file or library. I can try to delete them afterwards but it will be a little tricky to sort out the cells that have become top cells because they are no longer instantiated or present in the library.

    Anyway, the issue is only seen with OASIS. If you use GDS, the cells will be updated correctly, but again, orphan cells will appear as top cells in the B cases. Maybe that is a short-term workaround.

    Best regards,

    Matthias

  • edited November -1
    Becoming new top level cells is fine, that's easy for the user to delete from derivative.oas/gds.

    Ah. Too bad. I can't use gds, I have to use oas for the derivative file. Because I am using shape properties that are not compatible with GDS spec. Any scripting workarounds? (You don't need to make a polished script and post it, you could just briefly describe the idea and I'll try to create it myself.)

    Thanks a million,
    David
  • edited November -1

    Hi David,

    I just released 0.23.11 - this issue should be fixed then.

    Best regards,

    Matthias

Sign In or Register to comment.