"Manage Technologies" with Libraries

edited November 2015 in KLayout Support

Hi Matthias,

I notice that there is no mention of "Libraries" in the technology description: http://www.klayout.de/doc/about/technology_manager.html

Besides layers, python scripts, DRC, I would also like to include a fixed cell GDS library for inclusion. Is that possible?

Also, is it possible to merge the PCells and GDS libraries into one entry? Or better keep them separate?

Thank you

Lukas

Comments

  • edited November -1

    Under your KLayout home directory there is a folder called libraries. Amy gds or oas file in that folder is read, and becomes a static library. The cells available in the static library are simply the cells in that layout. To insert a static library cell, restart KLayout and choose Instance, then select the static library from the Library dropdown.

    I don't believe it's possible to have a combo PCell and static library.

    David

  • edited November -1

    Hi David,

    I am already using personal Libraries in my own .klayoutrc folder.

    This question is about packaging a technology for distribution to other people in a single folder / zip file. I'm wondering if I create a folder "libraries" in the specific "tech" folder, will it read it? or anywhere the search path, as discussed.

    thanks

    Lukas

  • edited November 2015

    Hi Lukas, hi David,

    I considered including libraries into the tech definitions, but the implications of such an entanglement are rather severe: when you switch the technology, do the libraries need to be switched too? What happens to cells not being there in the new technology? What happens to PCells being implemented differently? And so forth.

    So currently, there are libraries and technologies. Technologies mainly refer to layers, physical properties, verification and tooling (that's why you can associate scripts with techs - but that will only disable or enable them in the menu).

    If you want to provide some "design package", it's suggest to create a package with a structure identical to the ".klayout" folder: "libraries" for library files (GDS files which provide static layout for import), "macros" and "pymacros" for scripts and "tech" for technology files (for this refer to the "Auto-Import feature" here: http://www.klayout.de/doc/about/technology_manager.html) . Someone else can copy this package to any place and set $KLAYOUT_PATH to point to this location. The KLayout will read the setup from this there.

    Regarding the second question: PCells are always implemented in scripts, so they will be kept in "macros" or "pymacros" while static libraries need to be put into "libraries".

    Best regards,

    Matthias

  • edited November -1

    Hi Matthias,

    Regarding your idea of distributing the .klayout folder. Changing the $KLAYOUT_PATH would presumably use the new one, rather than the user default of $HOME/.klayout.

    So I could also provide a klayoutrc file, preconfigured to how I like to teach in class, with certain hotkeys, etc? Do you see any problems here with Linux/Windows/OSX differences in the klayoutrc file? I could trim the klayoutrc to have just the barebones perhaps, removing obvious things like paths, etc.

    Do you know what Windows people have to do to set $KLAYOUT_PATH? (sorry, I don't have one, so can't test this...)

    Anyway, it might be easier to stick with the regular "tech" approach you already have (file #1), and a separate GDS (file #2) which the user would have to figure out how to place in their .klayoutrc (which for computer-challenged people might pose a problem; e.g., how-to for windows??)

    thank you

  • edited November -1

    Hi Lukas,

    The configuration file is independent from the $KLAYOUT_PATH. The $KLAYOUT_PATH (for Windows: %KLAYOUT_PATH% ...) tells KLayout the locations for macros, GDS library files, auto-imported tech files etc. Multiple locations can be listed in a KLAYOUT_PATH and all of them will be scanned for such files. By default, the installation folder and the user-specific folder from $HOME/.klayout (%HOME%/Klayout on windows) is in the path. But you can override this default by using $KLAYOUT_PATH.

    The configuration file is looked up in $HOME/.klayout (%HOME%/KLayout), independently from $KLAYOUT_PATH. But initially, when you start KLayout for the first time if there is a "klayourc" file stored in the installation folder (beside klayout.exe), this file will be used to initialize the user-specific configuration file. This gives you a chance to provide a default initialization. Another option to achieve a custom initialization is to provide an auto-executed script which changes the configuration, the first time it's run. Here is a sketch (no tested):

    app = RBA::Application::instance
    begin
      app.get_config("testkey-config-initialized")    # throws an exception if not initialized yet (the key can be any string)
    except:
      app.set_config("background-color", "#000000")  
      ... more
      app.set_config("testkey-config-initialized")    # marks as initialized 
    end
    

    So distributing scripts and establishing an initial configuration can be one thing.

    In a company infrastructure, I'd suggest to share scripts by providing a central location and referring to that through $KLAYOUT_PATH. In a student environment it's maybe possible to provide an installer or a simple zip file which populates the student's ~/.klayout folder, provided it is extracted correctly. Another option is maybe to provide an extended installer which installs KLayout together with the custom scripts.

    Matthias

  • edited November -1

    Hi Matthias,

    Me and a few others I've spoken with are feeling challenged by the lack of ability to easily distribute both library and technology. We would like to use KLayout for different manufacturing processes, where each one would have it's own PDK (technology part, plus fixed cells and PCells). It would be great if the technology manager included some ability to do this.

    Right now, the best I can think of is for the user to place all the different libraries (fixed and PCells) in the pymacros and libraries folders. Then the user needs to be careful which components to use so that they match the technology. It seems that there should be a better way to handle this.

    Unrelated question: is it possible to read the Connectivity table in the Technology Manager, via script?

    Thank you

    Lukas

  • edited February 2017

    Hi Lukas,

    Linking libraries and technologies was my initial plan but it turned out that the implications of switching technologies become too severe in that case. One cornerstone of the architecture is that once a library in unlinked from a layout, it cannot be linked back. So when switching to a technology that does not have a certain library which you used inside your layout would basically detach your layout from that library forever.

    So a library cannot be dynamic, but it can come together with a technology package. To be frank, I don't recall the details, but here is the basic way: A technology has a "base path" which is telling it where to look for it's components. When you "auto-import" a technology from the "tech" folder the base path will point to the location of this technology file. "Auto-imported" technologies are basically a way of deploying technologies you have created manually in the tech manager. Deployment just means to install a subfolder with the data related to a technology inside the central or per-user configuration folder.

    The key for distributing code along with these packages is to create a sub-folder called "pymacros" or "macros" (for Ruby) inside that folder and put your macros there. They will be loaded when the technology is loaded initially (at startup, not when it's applied!). Nevertheless, this is your entry point for creating the PCell libraries.

    Finally you can use this point too to install static libraries. You can instantiate a static library through Ruby: a static library is not different from a PCell library but instead of adding PCells you load the library's "layout" object with a GDS2 or OASIS file of your choice. If you use a path relative to $0 (Ruby) or __FILE__ (Python) you can pull a GDS2 or OASIS file from within the folder without having to adjust paths.

    I'm aware that is just a sketch, but I'm fairly sure that is the way to go.

    Please note that "auto-imported" technologies are simply XML files (to get the structure export them from the technology manager). You can generate these files by some script too so that is one option to produce the connectivity information.

    To summarize:

    Inside /home/you/.klayout/tech create the following structure:
    
      your_tech/
        your_tech.lyt
        pymacros
          ... put your Python macros here ...
        macros
          ... put your Ruby macros here ...
    

    Then, KLayout should make the technology inside "your_tech.lyt" available on startup and execute the autorun-tagged Python or Ruby macros it finds inside the structure's pymacros and macros folders. This is your opportunity to install PCell and static libs.

    You can deploy this structure (everthing below and including "tech") to a central place (let $KLAYOUTPATH point to it then) or directly inside the KLayout installation, so every user gets these technologies without needing to install them.

    Regards,

    Matthias

  • edited November -1
    Hi Lukas,

    i had the same questions you have a time ago. I managed to have a "almost fine" solution using a small script and a csv file containing path to library and name of them. This way, each time a tech is selected, the script read the csv file and "instantiante" libraries which are descibed int the csv file. HEre is the script and the architecture of the csv file.

    Hope this help

    <?xml version="1.0" encoding="utf-8"?>
    <klayout-macro>
    <description>parse libraries</description>
    <version>1.1</version>
    <category/>
    <prolog/>
    <epilog/>
    <doc/>
    <autorun>true</autorun>
    <autorun-early>false</autorun-early>
    <shortcut/>
    <show-in-menu>false</show-in-menu>
    <group-name/>
    <menu-path/>
    <interpreter>ruby</interpreter>
    <dsl-interpreter-name/>
    <text>module MyLibraries

    include RBA
    require 'csv'


    # lecture de la liste des librairies à jour
    filename = "\\Pathtotech\librairies.lib"
    # la gestion des librairies se fait via une liste type csv
    csv_text = File.read(filename)
    csv = CSV.parse(csv_text, :headers => true, :col_sep=>';')
    # on lit le fichier

    count = 0
    #MessageBox::info("ATTENTION","Librairies liées, vous pouvez travailler normalement", count ,"librairies obsoletes", MessageBox::Ok)
    # affectation des librairies dans klayout
    csv.each do |row|

    name = "#{row[0]}" # nom de la librairie (tel qu'il apparaitra dans le menu)

    if "#{name[0]}" == "#" then

    count= count+1

    else


    libpath = "#{row[1]}" # chemin d'accès
    if File.exist?(libpath) then
    lib = RBA::Library.new
    lib.layout.read(libpath)
    lib.register(name)
    lib.description = "#{row[2]}"
    else
    message ="la librairie "+name+" n'existe pas"
    MessageBox::info("ATTENTION",message, MessageBox::Ok)
    end

    end
    end
    message ="Librairies liées, vous pouvez travailler normalement. #{count.to_s} librairie(s) obsoléte(s)"
    #MessageBox::info("ATTENTION",message, MessageBox::Ok)
    #else
    #MessageBox::info("ATTENTION","Librairies non liées, utilisation pour générer les fichiers destinés à la Maskshop" , MessageBox::Ok)
    #end
    end
    </text>
    </klayout-macro>


    librairies.lib
    library name;library path;commentaires et versionning
    test;\\pathtothestaticlib\foo.GDS;test A0
    #test_old;\\pathtothestaticlib\bar.GDS;test not ok

    P.S. the problem with that way of doing is that the static libs files are loaded in memory, which can make the memory footprint of klayout really big !!
    I recently changed the way of doing using the klayout_path environment var and a small launcher which is basically doing:
    update klayout_path with what we can call common tools/libs/tech (basically point toward a Common folder with the klayout hierarchy init (tech, macros, etcs)
    update klayout path with a path pointing towards the "product folder" you want to use.
    This way, you always have acces to "generic" or "common" libs, macros, etc and an acces to a product dedicated folder (containing also the klayout usual folder architecture).

    Regards
    Joël
  • edited November -1

    Thanks Joel. So your script loads the PCell libraries only, or GDS libraries? It seems to load all of the ones listed in the CSV, rather than selectively?

    How do you trigger an event based on selecting the technology? I would imagine unloading the unused libraries, and loading the one matching the chosen technology, each time the user clicks on the technology button. I don't see trigger code above.

  • edited November -1

    Hi Matthias,

    Similar question for you -- is there a way to trigger on the user changing the technology? i.e,. calling a Python script to unregister the other PCell libraries, and register the PCell library for the chosen technology? With more than 1 technology, I am concerned it will get confusing having incompatible libraries all listed. As I see now, I have a list of several GDS libraries, and several PCell libraries, all being loaded on start-up.

    thanks
    Lukas

  • edited March 2017

    Hi Lukas,

    I have not considered to unload PCell libraries so far. Basically it's possible, but the implications are severe and it will be difficult to catch potential interference scenarios. And once something is loaded into the Python interpreter space it's very difficult to get rid of it. Python is not built for dynamic removal of components too.

    You can basically load multiple layouts with multiple technologies, so the system needs to be capable of handling multiple technologies in parallel anyway.

    If you're worried about name clashes, you can put common code into separate .py files and "import" them. Python itself will make sure that this code is loaded only once. Regarding technology specific code, you may want to establish a consistent naming scheme. In Ruby you can use modules to isolate class names, in Python you can use "import" and separate .py files to put classes into their own module name space.

    Regarding listed libraries: only the libraries associated with the selected technology should be listed - for example when adding a cell. Isn't that true?

    Regards,

    Matthias

  • edited March 2017

    Hi Matthias,

     Regarding listed libraries: only the libraries associated with the selected technology should be listed - for example when adding a cell. Isn't that true?
    

    That part isn't working for me, which is essentially the question. I have presently 1 generic PCell library (for all technologies), and 2 technologies each with GDS and Python PCells, for a total of 5. When I instantiate a cell, the Library list shows me all 5. My configuration is as you described above (Feb 15), namely tech/EBeam/pymacros/SiEPIC_EBeam_PCells.lym, and tech/GSiP/pymacros/SiEPIC_GSiP_PCells.lym. They are both set to run on startup.

    I notice that the KLayout class "Library" does not know anything about technologies. Presumably the technology manager should take care of this, but it doesn't seem to be the case. Perhaps I'm missing something.

    Regarding static GDS libraries, as far as I can tell, tech/xxxx/libraries isn't read. So I had to put both technology static libraries in the global tech/libraries. Again, I might be missing something there too.

    Thank you
    Lukas

  • edited March 2017

    Hi Lukas,

    I stand corrected - Macros are associated with a technology. Libraries are not (currently). The focus of technologies wasn't libraries so far, so a library is not a true technology component yet. That's also the reason why tech/xxx/libraries isn't read.

    Making libraries technology components from within the system is possible, but that's a major piece of work.

    Since macros are technology components, they can be utilized to package libraries with technologies. A PCell library is always a script, hence that's supported out of the box. Static libraries can be instantiated with script code too. You can employ this way to load a static library local to the tech package.

    Here is the recipe:

    • Create a tech package folder in ~/.klayout/tech - for example mytech
    • Create a macros and layouts subfolder there
    • Put an initialization macro into the macros folder (i.e. init_libraries.rb) - see below
    • Put your static library into the layouts subfolder as static.gds (or use any name you want)

    Here is the code of init_libraries.rb:

    # $autorun 
    
    lib = RBA::Library::new 
    
    # TODO: adjust the layout name if required
    lib.layout.read(File.join(File.dirname($0), "..", "layouts", "static.gds"))
    lib.description = "From static.gds"
    lib.register("MyTech_StaticLibrary")
    

    You can use a .lym too - just make sure the "autorun" option is set. For a plain .rb file, the pseudo-comment "# $autorun" will do that. You can load as many layouts here as you like. Just use
    different library names in "register"

    Matthias

  • edited November -1
    Hello Lukasc

    my script is loading the gds files and give a name to the "library".
    It load whatever is found in the csv file.
    As Matthias commented, you can create easily a script for a given technology in the technology folder, which load the libraries you want.

    Joël
Sign In or Register to comment.