Basic.TEXT --> Convert To Static: Cell Naming

Comments

• Matthias

  February 6

  No, text string and cell name are entirely disconnected. The TEXT cell is a PCell which can be anything from a inductor coil to a memory block. Being a label does not qualify a PCell to decide about it's own name.

  Plus:

  • Text strings don't follow the cell naming rules
  • Names need to be unique, text strings don't

  As the text is only the label, why converting them to static cells anyway? If the reason is third-party compatibility, there are other options: convert in a post-production step by saving the final GDS without context or use OASIS.

  Matthias
• connan

  February 7

  Dear Matthias, thank you for the elaborate answer.

  I do understand, but the actual use case is a bit more complicated.

  First of all, its not really about a PCell to decide about its name, it is just about the inital name given. Which is now TEXT$XXX.

  The problem behind is, that I'm working with layouts from different developers which should be merged on a single die. So what I'm doing is parsing through a folder and adding the layouts to a library. The final layout then places the only the library objects. That way it becomes easy for the developers to adjust their layouts and the production layout is more or less automatically updated.

  The caveat with basic.TEXT is, that if you want to copy, lets say a row of labels into another layer, there is no easy way (to my knowledge) other than making the text objects static and copy the shapes. During this process it could happen that a 100 cells are created (Like TEXT$37). That's usually not an issue. But if that's the case for more than one of the partial layouts, there is an increasing chance of cell name duplets in the intermediate library. In this case, and that is really strange, the cells get merged. Meaning you will end up having both texts in a single cell. These errors are really hard to find and I want to avoid the situation and thus making the naming a bit more unique.
  I hope that makes things more clear. I would be happy to hear about any other solution.

  Kind regards
  Sascha
• tomas2004

  February 7

  Hi Sascha,

  1) What I normally do before merging gds files is giving each one of them a unique prefix, like "DIE1_", "DIE2_", etc. using the rename all cells script (https://www.klayout.de/useful_scripts.html#rename_cells.lym). This way you will not have the issue of having identical cell names between the gds files and after the merging all the cells are not mixed up and it is much clearer to see which cells belong to which layout, especially in "flat cell list" mode.

  Below, I merged 2 gds files which originally have the same cell names but I added the prefixes "DIE1_" and "DIE2_"

  

  "flat cell list" mode:

  

  2) I don't see the point of converting the text cells to static:

  a) the text pcell does list the layer and text parameters between brackets as shown above

  b) why not just copy and paste the text pcell instances and change the layer parameter of the copied instances?

  c) If pcells need to be converted to static, I would do that in each gds file to be merged before adding the prefix, so that they get the prefix of the design they belong to.

  Cheers,

  Tomas
• connan

  February 9

  Hi Tomas,
  thank you or your answers! Much appreciated.

  1)
  I have to think about renaming. Right now it's really convenient since I don't have to touch any of the partial layouts and this would incorporate an additional 'touch' on those.

  2)
  a) I'm aware of that (Y)
  b)
  That's the key point here. Consider having like 100 labels in the very top metal and you want to shift these into, let's say M3, that would mean touching every basic.TEXT object and changing the layer in the PCell-Context. That's really not an option here.
  c) that leads back to 1)

  Thank you again, I'm still not giving up on that topic. Maybe I'll create a script which modifies the PCells layer property then.

  One thing I still don't understand is why the Static TEXT$*** objects get merged if they are in a library. The usual behavior IIRC is that objects with the same name get overridden during the library creation process.

  All the best
  Sascha
• Matthias

  February 9

  Hi @connan,

  How exactly do you do the merge? When you say, you are adding them to a library, do you mean you are doing that in KLayout or is that some other tool?

  When you merge with KLayout, there are ways to avoid the name clash. Renaming like suggested by @tomas2004 is one way.

  When you merge with KLayout using something like:

  ly = pya.Layout()
  ly.read("a.gds")
  ly.read("b.gds")
  ...
  

  you can enable automatic renaming using:

  ly = pya.Layout()
  
  opt = pya.LoadLayoutOptions()
  opt.cell_conflict_resolution = kdb.LoadLayoutOptions.RenameCell
  ly.read("a.gds", opt)
  ly.read("b.gds", opt)
  ...
  

  Cell name conflicts are pretty common, not just for TEXT cells. So it is wise to take care of this issue in general.

  Matthias
• connan

  February 14 edited February 17

  Hi Matthias,
  'merging' is done via adding all the layouts to a 'per die' library which gets then created on startup.
  Here is an example for a SEM-Bar Library:

  import pya
  import sys
  from pathlib import Path
  from abc import ABC, abstractmethod
  
  #main library path
  base_path = r'I:\Layout_Library'
  
  #CNT library interface
  class ICNTLibrary(ABC):
    @abstractmethod
    def get_library_name(self):
      pass
    @abstractmethod  
    def get_library_description(self):
      pass
    @abstractmethod  
    def get_library_path(self):
      pass
  
  #CNT library base class
  class CNTLibrary(pya.Library, ICNTLibrary):
    def __init__(self):
      self.description = self.get_library_description()
      for file in self.get_library_path():
        self.layout().read(str(file))
        self.technology = pya.MainWindow.instance().initial_technology
        self.register( self.get_library_name() )
  
  #Implementation   
  class CNTLibSEMBars( CNTLibrary ):
    def get_library_name(self):
      return "CNT_SEMBARS"
    def get_library_description(self):
      return "sembars for general purpose"
    def get_library_path(self):
      return Path(base_path + r'\SEMBARS').glob('**/*.OAS')
  
  #Create instance
  CNTLibSEMBars()
  

  Thank you for pointing to the cell_conflict_resolution. Is there an easy way of doing something similar during the library creation process itself?

  Thank you!!
• Matthias

  February 17

  Hi @connan,

  for formatting code, please use a triple backtick line before and after the code. I fixed your previous comment.

  Regarding the code: I don't see the "cell_conflict_resolution" solution in your code. This loop has the cell conflict issue:

      for file in self.get_library_path():
        self.layout().read(str(file))
        self.technology = pya.MainWindow.instance().initial_technology
        self.register( self.get_library_name() )
  

  First I think, it should not include the last two lines:

      for file in self.get_library_path():
        self.layout().read(str(file))
      self.technology = pya.MainWindow.instance().initial_technology
      self.register( self.get_library_name() )
  

  and should look this way:

      opt = pya.LoadLayoutOptions()
      opt.cell_conflict_resolution = pya.LoadLayoutOptions.RenameCell
      for file in self.get_library_path():
        self.layout().read(str(file), opt)
      self.technology = pya.MainWindow.instance().initial_technology
      self.register( self.get_library_name() )
  

  Matthias