It looks like you're new here. If you want to get involved, click one of these buttons!
Hello,
I love PCells, but if I ever want to "freeze" or export them by converting them to static, the basic name plus an index is used. I would like to keep the meaningful name defined in display_text to keep the distinction between different instances of the same PCell, not just a number.
Is there a way to do it? (Other than the hacky and inconvenient way of accessing the layout from pya.Application and try to map which is which)
I understand the reasoning for keeping the basic name in order to identify them when reloading libraries. Maybe this is the preferred way of having PCells converted (reason unknown to me), but having an internal PCell flag to the display_text insead seems to me like a very nice addition when executing Convert To Static Cell. I checked dbLayout.cc and it seems feasibe.
Thanks!
Gerard
Comments
Hi Gerard,
no, the "display name" is meant for the eye and usually contains illegal characters such as brackets or similar. Usually it also does not capture the full intent of the cell, so it may not be unique. Keeping different domains separate is essential, so a human-only name must not become a formal one.
What you look for is a new API feature - i.e. "static_name" or something like this.
But if it is about encoding the PCell configuration - how about placing a text into the cell describing the PCell parameters? That will survive conversion to static cells and also is persisted in GDS without loss.
Matthias
Hi Matthias,
Thank you for answering.
Placing a text wouldn't do it as we do want it as the cell name so that we can differentiate cells without opening them, or filter the cells with ease.
Uniqueness of the name I believe is the least of problems: the same
$napproach as the current one orpya.Layout.unique_cell_name()could be used for each static conversion, and all illegal characters can be cropped during conversion, or even prevented raising an error. The name fully describing the PCell would depend exclusively on the PCell implementation, not the API of course (although it has all info that makes the PCell unique🤔)I agree that a dedicated variable for this purpose would be best as you suggest, and I'm aware that what I'm proposing is not the intended usage. But alas it's a feature that already exists and it just needs to be connected internally with, I would dare say, minimal development.
display_titleis intended mostly for PCells and with limited scope currently (cosmetic only), and making the proposed behaviorOFFby default would prevent confusion. And there's alreadyname,qnameandbasic_nameapart fromdisplay_title. Adding a fifth I think would make it a bit messy.With all this said though, you will know best for sure haha.
Best regards,
Gerard
Hello,
What about placing a text into the PCells (without illegal characters) describing the PCell name & parameters, like Matthias proposes, on a dedicated layer, convert them to static and run a simple secondary script to rename cells which contain a text on this dedicated layer to the string of that text???
Cheers,
Tomas
Hi Tomas,
That's quite the workaround haha. Somewhat inconvenient, but that'd work yes.
Thanks for your input!
Gerard
You could combine the converting to static and renaming in one script... However, it's no solution for the pre-defined Basic PCells, if that's what you want to rename as well...
Cheers,
Tomas
Hi @Tabra,
I'm not proposing a fifth function for
Cell, but for the PCell API. Currently the PCell delivers the "readable" name by "display_text_impl". By "readable" I mean "readable" and I learned to keep formal and descriptive names apart the hard way.My proposal boils down to adding a new PCell API method, namely "static_name" or "cell_name" and you can implement it to encode your formal name for the PCell - including the parameters. That's backward compatible - if you don't implement it it will use the PCell name and has potential for being of use everywhere - not just in "convert to static cell". I have created a feature for that here: https://github.com/KLayout/klayout/issues/2195
Until then the workaround proposed by @tomas2004 is a nice one - that even adds documentation to the layout
Matthias
Hi Matthias,
Ooh now I understand what you meant. That will be awesome to have.
Thank you very much, what a marvel of software!
Gerard