Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

PCell development introduction - Questions for KLayout

Hi all,

I’m new to KLayout, so a lot of things may be uneasy to understand with a first glance.

In general, I am interested for the PCell development and I am trying to use the idea of this example as a base: https://www.klayout.de/forum/discussion/comment/4444#Comment_4444. I am trying to build a dummy GSG, with some extra features that I want to add, mainly into the PCell Parameters UI.

1) Firstly I wanted to ask if there is any progress with the callbacks invoking via parameters change. I found the following thread where a similar problem is being discussed, where Matthias said back in 2015 that “only Apply will set the parameters”.
https://www.klayout.de/forum/discussion/630/parameter-changes-in-pcells-not-always-working-correctly

I noticed that changes into drop-down lists invoke the callbacks, so I feel that I do something wrong instead.

2) Maybe I misunderstood the usage and the actual meaning of the ‘hidden’ keyword of the parameters declaration, but I am trying to build an interactive Parameters UI where by setting either ‘On/Off‘, different parameters will be displayed into the form (e.g. If the user wants only the signal line of the GSG, he could close the ground signals by an ‘On/Off’ option, and the parameters that refer to the ground lines should be hide from the form and be set into their default values via callback).

Changing the ‘myParam.hidden’ value doesn’t seem to have any effect into the form, although the parameter itself seems to keep the correct information. I do the checking and the parameters correction into the ‘coerce_parameters_impl’ procedure of the PCellDeclarationHelper. Is there any way I could do the form interactive using the ‘hidden’ keyword, or with some other methodology? I also tried the ‘myParam.readonly’ option but it didn't help either.

3) I use the FreePDK45_tech that is provided by the Package Index for metal layers. That I want is a dropdown list of specific layers (e.g. only the ‘metal#.drawing’ metals), so the user can choose only between them and not from the entire layer list. I want to pull somehow the layers and their indexes into the pcell implementation, to build the list and use it with the ‘myParam choices’ attribute of the parameters declaration. Following the documentation and the forum threads I couldn’t find any working solution.

Maybe I could create in a third location a global accessed variable, where I could find this layer list, initialize it with the metals and then use it inside the PCell with some filtering, depending the usage. I was thinking to add a metal stack option to my example so the vias will also be needed, so I will need to know the indexes without the providing of the information by/to the user.

Generally I want to understand the hierarchy of the KLayout and its main window. I think that I found the layout method where the shapes are drawn. Please correct me:

app = pya.Application.instance()
mw = app.main_window()
layout = mw.current_view().active_cellview().layout()

Which I think is equal to :

active_layout = pya.CellView().active().layout()

app = pya.Application.instance()
mw = app.main_window()
layout = mw.current_view().active_cellview().layout()
active_layout = pya.CellView().active().layout()
layout

<pya.Layout object at 0x7efd63aefbb0>

active_layout

<pya.Layout object at 0x7efd63aefbb0>

And the temporary layout that the shapes of the pcell is drawn before it be placed as an instance is (if that’s the case):

pcell_layout = self.cell.layout()

How I could reach the Layers section and view its information (layers and indexes)? I think the corresponding methods from Layout is ‘layout.layer_indexes()’ and ‘layout.layer_infos()’.

4) I think I found a minor bug regarding layers and layout where layout.find_layer does not work when you give only the name of the layer as a string for the search. Following I provide the test case:

active_layout = pya.CellView().active().layout()

myLayer = pya.LayerInfo( 23, 5, 'myLayer')
myLayer

myLayer (23/5)

active_layout.layer(myLayer)

print active_layout.find_layer(23,5)

1

print active_layout.find_layer(23,5,'myLayer')

1

print active_layout.find_layer('myLayer')

None

active_layout.get_info(1)

myLayer (23/5)

5) It seems that I fail to understand how to create a shape on a layout and a cell that I created by my own. Could it be that I don’t set the cell as editable? If that is the case, how I enable it? I tried the layout.update() method with no results. Sample of code I run:

app = pya.Application.instance()
mw = app.main_window()
cv = mw.create_layout(1)
active_layout = pya.CellView().active().layout()
cv.name = 'myLayout'
cell = active_layout.create_cell('myCell')
myLayer = pya.LayerInfo( 23, 5, 'myLayer')
active_layout.layer(myLayer)
mySecLayer = pya.LayerInfo( 32, 50, 'mySecLayer')
active_layout.layer(mySecLayer)
active_layout.layer_infos()

[myLayer (23/5), mySecLayer (32/50)]

layer_indexes = active_layout.layer_indexes()
layer_indexes

[0L, 1L]

cell.shapes(layer_indexes[0]).insert(pya.DBox(0, 0, 1000, 1000))

box (0,0;1000000,1000000)

6) One more observation is that the Layers section in the main window does not display always the layers that I add. I wanted to provide a test case but I wasn’t able to understand when it display them and when not. I would say its arbitrary but it doesn’t feel like that.

7) PCell template was a lot of help along with the PCell sample from macro development. Extra help was given by the examples of FreePDK45 about the technoly usage and from the ShapeLib for the PCell development. Except these sources, is there any other source of information about pcell development using KLayout with python? I am also interested for tutorial of how to make custom technologies or converting existing ones to KLayout compatibles.

Thanks in advance,
(and sorry for the long post I wanted to collect a lot of questions before I post,)

Chris

Comments

  • Hi Chris,

    This really is a long post. Here are some answers:

    1.) you're probably not doing something wrong. I'm not aware that drop-down list changes would trigger callbacks. That's kind of questionable as the contract is that layout won't change until you hit Apply. I'd call that a bug.

    2.) The parameter UI is pretty simplistic. It's built for showing and editing a list of parameters is a more or less fancy way, but not more. "Hidden" is intended for (computed or internal) parameters which are not meant to be shown. The circle PCell for example uses the hidden "actual radius" to store the radius it really uses. This is necessary as input may come from two lanes: from the edit field and the handles. Both need to be synchronized. The hidden parameter helps deciding which is the value that has changed.

    But hidden (and the other parameter attributes) can be changed dynamically. Sorry.

    3.) This also will be difficult. The PCell class does not have access to the layout environment (this includes technology) by design, except in cases when actual layout has to be generated.

    It's possible to provide libraries per technology, so basically you can specialize a PCell for a technology: implement a generic base class in a general module, then derive a class for a given technology with a technology-specific list of layers you want to display. This has been done already. But I just found https://www.klayout.de/forum/discussion/comment/5231#Comment_5231 for this topic, but I'm sure there is more.

    Bottom line is: don't try to reach the actual layout - it's hidden behind many layers. KLayout wraps a lot of cache and library indirection code around the PCell. The layout object you'll get very likely not even the one you're placing the PCell on.

    4.) Depending on the format, the layer name is not the primary identifier for a layer. For DXF and CIF it is, for GDS and OASIS it isn't. For those formats, the layer number and datatype number are the primary identifiers for the layer, not the name. Even though the name can be specified in OASIS, it's still just an annotation and may not even be unique.

    5.) A layer does not become visible automatically (layers in the layer list are just "views" and may be super- or subsets of the actual layers). To make all new layers visible, use "RBA::LayoutView::current.add_missing_layers".

    6.) Maybe 5.) is related to this?

    7.) I guess you know this one: https://www.klayout.de/doc-qt4/programming/ruby_pcells.html. It says "Ruby", but the translation to Python should be pretty straightforward. There is a lot of code in the forum and some in the packages - I guess it's worth scanning that.

    My advise is to think of PCells as something very simple. The intention behind that was the kind of thing the circle PCell does. Everything more elaborate than this goes beyond the intention of the design, so I'd be careful.

    For more advanced use cases, a "layout generator" might be more useful. For example a memory generator will never fit into a PCell. So it's always implemented as a system that generates a cell which you can then include (through some substitution process) into your layout.

    Kind regards,

    Matthias

  • edited May 13

    Hi Matthias,

    Thank you for your response, and again sorry for the long post I wouldn't like to spam the forum with many questions.

    2) It would be a very nice feature for the future in my opinion :smile: . It would make a bigger an more complicated form more clean and structured.

    3) I'm not very sure if I understood what you meant but I'll do a research first and I will come back to a new post If that is necessary. I only got that I can't do what I've wanted :smiley:

    6) Yes 'add_missing_layers' I think is the answer to my question, thank you!

    7) I thought Ruby and Python contain the same corresponding things. I 'll check it out.

    ================== Still Open =====================

    1) It doesn't update the generated geometry in layout, it just corrects the "faulty" parameters of the form. I have to press apply to see the changes in the geometry. Mainly that is what I wanted, when I change a parameter's value, and then I click outside the parameter's textfield, to trigger the callbacks the same way a change in the drop-down list does.

    4) So its deprecated to search a Layer by name? If a layers name isn't unique it should return a list of the layers with the same name in my opinion, but anyway, in the test case it is unique.

    5) It has no effect. With 'add_missing_layers' I can see the layers now, but I still can't draw a shape with the last command I use. Even when I click to a layer, then click to 'myCell', and then I click the 'Box' button to draw a shape by hand, there is an error message that pop ups saying 'Please select a cell first'.

    Also I observed that the name of the layout tab do not contain the last bracket section (e.g. a layout created by 'File'->'New Layout' : [+] L2 [testCell] -- a layout created by commands : [+] myLayout )

    Chris

  • edited May 13

    Hi Chris,

    regarding 1.) the parametrization is a two-stage process: the parameters are edited and then transferred to the PCell in "Apply". Only then the layout is modified. While editing, "coerce_parameters" is called to "fix" the parameter configuration - e.g. to ensure parameters to be compatible or within a certain range. Only the parameter values can be modified. Parameter attributes such as name, description, type and hidden flag are static.

    4.) yes, for OASIS and GDS it is. The name is just an associated attribute in OASIS, nothing more. No key. Layer and datatype numbers form the key.

    5.) In this case you also need to select the cell which is selected in the view, e.g:

    RBA::CellView::active.cell = RBA::CellView::active.layout.top_cell
    

    This also explains why the brackets are missing - this is the cell name.

    Matthias

  • Hi Matthias,

    4) It would make it easier to search by name though, and then filtering that result, or just be used as a preview. But thanks for clearing this out, I thought I was doing something wrong. I suggest that the second paragraph has to be enriched with your answer also in the documentation:

    4.) Depending on the format, the layer name is not the primary identifier for a layer. For DXF and CIF it is, for GDS and OASIS it isn't. For those formats, the layer number and datatype number are the primary identifiers for the layer, not the name. Even though the name can be specified in OASIS, it's still just an annotation and may not even be unique.

    5) Thank you, that really did the trick. So, for later review, the commands are:

    app = pya.Application.instance()
    mw = app.main_window()
    cv = mw.create_layout(1)
    active_layout = pya.CellView().active().layout()
    cv.name = 'myLayout'
    cell = active_layout.create_cell('myCell')
    pya.CellView().active().cell = pya.CellView().active().layout().top_cell()
    myLayer = pya.LayerInfo( 23, 5, 'myLayer')
    active_layout.layer(myLayer)
    layer_indexes = active_layout.layer_indexes()
    pya.LayoutView().current().add_missing_layers()
    cell.shapes(layer_indexes[0]).insert(pya.DBox(0, 0, 1000, 1000))
    

    If there is a better way to do the same thing, please let me know.

    ================== Still Open =====================

    1) So in the first step, while editing, there is a functionality where the "coerce parameters" is called to "fix" the parameter values when a change to a drop-down list happens, before the second step, where the parameters transferred to the PCell with "Apply".

    How I can use that functionality in all changes, regardless the type of the parameter? I imagine that this functionality exists for all the types and not only for the 'TypeList'.

    I want to trigger the callback mechanism after every change without pressing always the "Apply" button after an event, just like the 'TypeList' effect .

    7) Regarding the resources of information for KLayout, I feel that the multilevel of the tool could be chaotic for a beginner like me. What you suggest could be the steps for getting closer to learn the tool, and the PCell subject subsequently?

    Also, is there any class diagram or any graph in general for showing the relations (like the one you showed me in 5.)? This may help me better understand of how to use klayout.

    Thanks in advance,
    Chris

  • Hi Chris,

    for 1.) I just can say the "coerce" function is called latest on Apply. Using it for dynamic normalization isn't a use model I had in mind and I'd say it's coincidence rather than intention that it is called on a change of a combo box value.

    So if you want to make dynamic normalization part of the specification, there always is the option to suggest a code change and submit a pull request. That's what open source is about.

    for 7.) I never claimed that PCell programming is simple. Simple PCells are easy to code, but what you are doing is beyond the simple case. Simple means: parameters in, layout out. Like the Circle PCell. With this, you don't need to care about the details how KLayout manages PCells. Such a case is a straightforward transformation of values into layout and this is what KLayout's PCells were built for. Try to stay within this framework and you'll be more lucky.

    And no, there is no class diagram. I have only two hands, ten fingers and my day has 24 hours only. It's past midnight for me now, I need to get some sleep and I'm not getting paid for this. So please don't expect too much. But you're cordially invited to contribute documentation and share it.

    Matthias

  • Hi Matthias,

    Thank you for your responses, and sorry for any inconvenience I caused.

    For 1), you can think it like something you meet in memes "Its not a bug, its a feature!" :)

    Regarding 7), in the future, I hope I can contribute something to this tool also. Is still the beginning for me, learning how to use this powerful tool, so I keep notes of what I can, and can't do, like this thread. I'm very interested of how to get the best out of it, and why not, helping making it better.

    Chris

Sign In or Register to comment.