Not signed in (Sign In)

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

    • CommentAuthorlukasc
    • CommentTimeNov 17th 2015

    Hi Matthias,

    I notice that there is no mention of "Libraries" in the technology description:

    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



    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.


    • CommentAuthorlukasc
    • CommentTimeNov 17th 2015

    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.



    • CommentAuthorMatthias
    • CommentTimeNov 19th 2015 edited

    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: . 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,


    • CommentAuthorlukasc
    • CommentTimeNov 19th 2015

    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

    • CommentAuthorMatthias
    • CommentTimeNov 19th 2015

    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
      app.get_config("testkey-config-initialized")    # throws an exception if not initialized yet (the key can be any string)
      app.set_config("background-color", "#000000")  
      ... more
      app.set_config("testkey-config-initialized")    # marks as initialized 

    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.


    • CommentAuthorlukasc
    • CommentTime6 days ago

    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


    • CommentAuthorMatthias
    • CommentTime5 days ago edited

    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:
          ... put your Python macros here ...
          ... 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.



    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"?>
    <description>parse libraries</description>
    <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 =
    csv = CSV.parse(csv_text, :headers =&gt; true, :col_sep=&gt;';')
    # 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


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

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

    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).