Technology initialization script

edited July 2017 in Python scripting

Hi Matthias,

When the user clicks on a technology, it triggers a reload of the specified layer properties file. Is there a way to add more actions to this? Specifically, I would like to have an init script called when someone changes the technology in which I define some global variables. These variables are then used by my PCells. I would like PCells to be general and applicable to multiple technologies, but with technology-specific parameters (e.g., different default layers, different feature sizes, etc).

Thank you

Lukas

Comments

  • edited July 2017

    Hi Lukas,

    you can associate macros with a technology, but that just means that macro is shown in the menu only if the specific technology is selected. So that does not solve your problem.

    I'd in general discourage from making PCell code depending on global variables. PCell code may be executed on occasions beyond your control. Basically multiple layout objects can live in the KLayout object space and there is not necessarily one "active" layout. There may be occasions when the other layouts want to evaluate their PCell code as well - and in their technology context.

    With 0.25 it's possible to associate a library with a technology. That does not mean the library is tied strictly to that technology, but a user that has a layout with a certain technology will only see the libraries associated with this (or no specific) technology.

    Using this feature, my approach to solve your problem with 0.25 was to derive a bunch of libraries from a basic implementation. So no code duplication.

    Like this (just a sketch - not tested):

    class GenericPCell < PCellDeclarationHelper
    
      def initialize(tech_specific_par)
    
        @tech_specific_par = tech_specific_par
    
        # Important: initialize the super class
        super
    
        # declare the parameters
        param(:l, TypeLayer, "Layer", :default => LayerInfo::new(1, 0))
        ...
    
      end
    
      def produce_impl
    
        ... produce the layout using @tech_specific_par and the user parameters ...
    
      end
    
    end
    
    class MyGenericLib < Library
    
      def initialize(tech, tech_specific_par)
        layout.register_pcell("MyPcell", GenericPCell::new(tech_specific_par))
        self.technology = tech   # Requires 0.25 !!!
        register("MyLib_" + tech)
      end
    
    end
    
    # Registers a library "MyLib_TECH1" for technology "TECH1" with technology specific parameter "1"
    MyGenericLib::new("TECH1", 1)
    
    # Registers a library "MyLib_TECH2" for technology "TECH2" with technology specific parameter "2"
    MyGenericLib::new("TECH2", 2)
    
    ...
    

    In other words, the approach is to install the same library multiple times with different variations. Because each library is tied to a specific technology, it will become visible in the library browser only for this technology.

    How about this?

    Matthias

  • edited November -1

    Hi Matthias,

    This makes sense. I don't have 0.25 so can't test this yet.

    One question is what types of parameters can be stored in the technology. Hopefully it will be generic enough (i.e., not just the layer table) that I can put any number of variables that I want for my application (e.g., thickness values, wavelength, radius, layer assignments, etc); these variables can be simple strings that I parse to get my information.

    Thank you

    Lukas

  • edited November -1

    Hi Lukas,

    sorry for coming back this late ... Actually, this approach can story any kind of parameter. The above example uses a single integer, but you can extend the list of parameters to any number and type.

    Regarding 0.25 the master on GitHub is fairly stable now. I am ready to provide Windows and Linux builds, but MacOS I have not had any feedback so far.

    Regards,

    Matthias

  • edited November -1

    Hi Matthias,

    We are finally getting some time to work on this, on 0.25:

    I am running into the following challenge:

    • Multiple technologies
    • We want to use generic names for layers in the PCells, rather than hard-coding "1/0". Example, "Waveguide" for 1/0.
    • The PCells are in pymacros in the tech folder
    • We want the PCell param defaults to be layers based on the technology layer map, using the look-up (e.g., Waveguide).
    • I want to read the layer table from the technology.
    • I can get the tech details using:
      pya.Technology.technology_by_name(tech_name).to_xml()
      but this doesn't include the layer table

    • I can find the path I can't figure out a way to read the layer table. LayerProperties doesn't seem to have a method to load a lyp file.

    I can probably implement a solution using an XML to dict parser, by loading the lyp file directly. But you already implemented that somewhere...

  • edited November -1

    I implemented an XML to dict parser, followed by scanning through and finding all the layers to create a layer dict...

  • edited November -1

    Hi Lukas,

    One solution for this is to create a temporary (and otherwise unused LayoutView object):

    lv = RBA::LayoutView::new
    lv.load_layer_props("path-to-your-lyp")
    lp = lv.begin_layers
    while !lp.at_end?
      puts lp.current.name
      lp.next
    end
    lv._destroy
    

    A LayoutView is not a lightweight object, so this should not be done frequently.

    In general however, I'd prefer to have named database layers. On of the features of technologies is to specify layout reader properties. This allows GDS layer mapping so you can basically assign database layer names on reading (DXF, OASIS and CIF support layer names natively).

    If you have names DB layers their names should be shown in the drop-down boxes for the layers and not lyp file parsing or other name translation should be required.

    How about this?

    Best regards,

    Matthias

  • edited November -1

    Thank you. This works well for loading the layer table from file.

  • edited November -1
    Hi LucasC, I did the same with a Python script. I can go from the .map files to Mentor CalibreDRV or KLayout. Also I can write the tech file. I'll make a package when I find a bit of time.
Sign In or Register to comment.