document pcells implicit dependency on gdsfactory

[proppy]

When starting klayout, the following error is raised when gdsfactory is not installed causing the pcells not to load:

ERROR: /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/draw_fet.py:22: No module named 'gdsfactory'
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/draw_fet.py:22
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/fet.py:19
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/__init__.py:21
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/gf180mcu.lym:9 (class ModuleNotFoundError)

This effectively means that the PDK is now dependend on gdsfactory, we should make sure that this is explicitly documented (as most people won't have it installed by default when using klayout and/or volare).

My feelings is that we'd prefer the base klayout integration not to depend on gdsfactory, and have a separate gdsfactory based PDK similar to what @joamatab did with https://github.com/gdsfactory/skywater130/.

curious what @mithro and @joamatab thinks?

[proppy]

Looks like the dependency was introduced in 5805c8fac0ba09a17b850288198bb228243f2ee2

[joamatab]

yes, i agree that we should keep the gdsfactory PDK separate from the pure klayout PDK, so we avoid implicit dependencies the gdsfactory flow is meant to be used for the python scripted flow and should be install-able through pip

if you want to keep it this way we can create a klayout package for gdsfactory and gf180 pdk and mark it as a dependency

[atorkmabrains]

@proppy and @joamatab

We had the pure klayout implementation before. Due to the more powerful tools provided with gdsfactory, I decided to remove the pure klayout implementation. gdsfactory has very strong tools allowing easier manipulation of pcell code and parameterization.

BTW, https://github.com/gdsfactory/skywater130/ might be old implementation for the pcells and also this repo is for skywaters which different than gf180mcu pcell implementation.

As for the requirement of GDS factory, Please check the requirements.txt file. It lists gdsfactory as a requirement.

[atorkmabrains]

@FaragElsayed2 Could you please add the documentation that the user need to install the requirements.txt?

[proppy]

As for the requirement of GDS factory, Please check the requirements.txt file. It lists gdsfactory as a requirement.

But that would get installed in the Python environment embedded in klayout per default, and gdsfactory also brings native dependencies like gdstk that mirror some of the functionality already present in klayout.

BTW, https://github.com/gdsfactory/skywater130/ might be old implementation for the pcells

That's a PDK specifically for gdsfactory, so it's meant to be used outside of klayout when working directly on a design with gdsfactory.

We had the pure klayout implementation before.

That seems desirable to keep this for the klayout integration, and to have a separate gdsfactory PDK for usage within the gdsfactory ecosystem.

[atorkmabrains]

@proppy https://github.com/gdsfactory/skywater130/ was written to work with Klayout mainly using gdsfactory backend.

[atorkmabrains]

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

[proppy]

@proppy https://github.com/gdsfactory/skywater130/ was written to work with Klayout mainly using gdsfactory backend.

I don't think that's the case, according to https://gdsfactory.github.io/skywater130/notebooks/intro.html this is mainly design for interactive/scripted usage within a regular python environment outside of klayout.

[proppy]

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

This does have some implication on packaging, and making sure the dependencies are accessible from the klayout environment.

Additionally, this most likely would end up installing the klayout wheels inside the klayout python environment (since gdsfactory depends on it), so I'm assuming we'll effectively end up with two duplicate copy of klayout pya and klayout.db within the same process?

[atorkmabrains]

I don't think that's the case, according to https://gdsfactory.github.io/skywater130/notebooks/intro.html this is mainly design for interactive/scripted usage within a regular python environment outside of klayout.

@proppy We are the ones who developed those pcells. @joamatab took what we have and taken our backend implementation to demonstrate how gdsfactory works for analog pcells as well.

Our intent was to allow both use cases, scripted through gdsfactory and interactive using klayout with the same backend implementation.

@joamatab Could you please comment on this?

[atorkmabrains]

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

This does have some implication on packaging, and making sure the dependencies are accessible from the klayout environment.

Additionally, this most likely would end up installing the klayout wheels inside the klayout python environment (since gdsfactory depends on it), so I'm assuming we'll effectively end up with two duplicate copy of klayout pya and klayout.db within the same process?

yes it may have some issues. but careful usage and documentation should help. For the interactive user, it would be seamless according to our testing.

[proppy]

@proppy We are the ones who developed those pcells. @joamatab took what we have and taken our backend implementation to demonstrate how gdsfactory works for analog pcells as well.

Are you referring to this PR? https://github.com/gdsfactory/skywater130/pull/40/

Our intent was to allow both use cases, scripted through gdsfactory and interactive using klayout with the same backend implementation.

Wouldn't it make sense to use klayout 'pya` as the lowest common denominator? is gdsfactory able to import a klayout pcells and expose them as a component?

The alternative could be to make the backend of gdsfactory plugable, so that it can work both when embedded in the klayout app (importing pya) and in standalone mode using using pypi's klayout (importing klayout.db).

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

This does have some implication on packaging, and making sure the dependencies are accessible from the klayout environment: Klayout has it's own way to discover python dependencies which differ from platform to platform, see the paragraph on https://www.klayout.de/doc-qt5/programming/python.html#:~:text=The%20Python%20macro,Python%20%3E%3D%203.x). about KLAYOUT_PYTHONPATH usage.

yes it may have some issues. but careful usage and documentation should help. For the interactive user, it would be seamless according to our testing.

Currently the PDK is distributed as a standalone archive thru volare which doesn't include an automated way to python -m pip install additional dependencies.

gdsfactory also comes with a lot of dependencies that you don't actually need for drawing pcells (netlist editing, routing, 3d rendering, simulator interface, etc), so unless the primitive are exposed as separate package (https://github.com/gdsfactory/kfactory?) you would require the users to install transitively a lot of unecessary packages.

On possibility avenue could be to bundle the drawing primitive from gdsfactory as a standalone pure python module that we vendor and distribute with the klayout pcells as part of the pdk build process.

Maybe https://www.klayout.de/doc/about/packages.html#:~:text=the%20subversion%20equivalent.-,Installation%20Hooks,-Scripts%20can%20register could be useful here, if we were packaging the klayout integration as a klayout package, we could rely on hooks to fetch/install dependencies.

@klayoutmatthias @joamatab @mithro any thoughts here?

[mithro]

@joamatab - Any thoughts?

[joamatab]

At the moment, the gdsfactory klayout package only contains the gdsfactory klayout integration (live updates, shortcuts ...)

We can register gdsfactory as a klayout package and mark it as a dependency for the gf180mcu-pdk

[atorkmabrains]

@proppy and @mithro original PCells for skywaters 130nm written using GDS Factory: https://github.com/efabless/sky130_klayout_pdk/tree/main/sky130_tech/tech/sky130/pymacros/cells

[joamatab]

it actually works well on linux, but probably not yet on MacOs and Windows

you can install gdsfactory as part of the pdk initialization

https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/pull/33/commits/aa99e0149f2716c8001bd101998b96638fc948dc

[joamatab]

Amro, the run drc does not work from the macro @atorkmabrains

[proppy]

@joamatab is gdsfactory using pya and not klayout.db when ran inside klayout?

[joamatab]

gdsfactory uses klayout.db only, but is an optional dependency for nicer visualizations

the way mabrains did gf180 is different from the skywater 130nm pure python package (which does not use klayout API at all) i prefer this type of packaging where you can pip install sky130

in the sky130 the klayout integration provides layercolors, DRC ... but not PCells on the GUI

[proppy]

@joamatab the thing I dislike about the current gf180mcu pcell integration, is that it will leverage gdsfactory to save a temporary gds file to disk and then re-read it thru klayout API to integrate it in the current layout, see: https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/cells/klayout/pymacros/cells/draw_fet.py#L2693-L2694

If we want to use an higher level API like gdsfactory, I'd prefer us to do so on top of existing klayout pya primitive, maybe kfactory could allow this? (see https://github.com/gdsfactory/kfactory/issues/53).

[proppy]

Another question for @joamatab, would it make sense to provide an alternative klayout backend in gdsfactory, where pya or klayout.db/lay can get used instead of gdstk when serializing the cells here: https://github.com/gdsfactory/gdsfactory/blob/9c2c9727642eff8f877e717e76218249283b5c78/gdsfactory/component.py#L1709-L1713

Happy to contribute here too if you think it makes sense.

[sebastian-goeldi]

There is a test ongoing for that. For that case I wrote the CplxKCell https://github.com/gdsfactory/kfactory/blob/main/src/kfactory/kcell.py#L1620 . This will allow a rather quick integration of kfactory into gdsfactory

Although these cells have a risk of being off grid unless proper care is taken (no safeguards in there yet).

[atorkmabrains]

@proppy what's the final decision here?

[proppy]

The current implementation that serialize the gds to disk using gdstk before re-reading it with klayout api doesn't seem desirable: https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/cells/klayout/pymacros/cells/draw_fet.py#L2693-L2694 for the following reasons:

• create _temp.gds files in the current directory without a strategy for cleaning them up
• it introduces a dependency on native package (gdstk) that might not be available for all platform (ex: arm64 macosx)
• it breaks the static distributions of the PDK with volare and open_pdks requiring the users to run an extra command (python -m pip install gdsfactory) in order to get a functioning PDK
• it complicates the packaging of the PDK within conda-eda as we don't currently have gdsfactory package with all its dependencies there

My recommendation would be to revert to using klayout built-in PCells API (pya) rather than gdsfactory until we converge on the options discussed with @sebastian-goeldi and @joamatab in the comments of this issue, but I'd love to hear what other people think too (@mithro, @joamatab, @donn, @RTimothyEdwards, @xobs)

[atorkmabrains]

@proppy Just a point here, the original implementation was not as robust from generating the Pcells as this one. Please keep in that in mind.

[proppy]

@proppy Just a point here, the original implementation was not as robust from generating the Pcells as this one.

Was it due to gdsfactory providing higher level API? or is there something else that caused the lack of robustness in the previous klayout implementation?

[atorkmabrains]

@proppy Yes, gdsfactory is much better in handling relative objects than regular klayout. Also, I still recommend not to move gdsfactory to use klayout backend and to try to keep using gdstk instead as gdstk is much better in handling large data and much faster in dealing with memory than klayout. Klayout is a great tool for many things, but I think gdstk has it's niche in speed, memory consumption robustness and other factors.

As for gdstk, I believe it could be compiled for arm and macosx that shouldn't be a problem.

[sebastian-goeldi]

create _temp.gds files in the current directory without a strategy for cleaning them up

Why does gdsfactory have no strategy to clean them up? That seems like an oversight. You can easily clean them up after klayout is done loading.

[proppy]

Why does gdsfactory have no strategy to clean them up? That seems like an oversight. You can easily clean them up after klayout is done loading.

This is not really gdsfactory responsability, those temporary files are currently created everytime a user draw a pcell on their layout, which I don't think is desirable (for obvious reason?)

[atorkmabrains]

@proppy we could clean up the temp files. It might have been an oversight on our end. I believe that shouldn't be a hard change to make.

[proppy]

Klayout is a great tool for many things, but I think gdstk has it's niche in speed, memory consumption robustness and other factors.

Keep in mind that with the currently implementation you're still exercising klayout GDS handling code when loading back the layout from disk.

The current path does:

1. build a gdsfactory memory models of the pcell
2. translate gdsfactory memory model of the pcell into gdstk memory model
3. ask gdstk to serialize its memory model of the pcell to disk
4. ask klayout to read the pcell GDS from disk and built its memory representation
5. include klayout memory representation in the current layout

The previous path only involved (5) so I think we should question that it is more robus and effective.

[sebastian-goeldi]

Yes, gdsfactory is much better in handling relative objects than regular klayout. Also, I still recommend not to move gdsfactory to use klayout backend and to try to keep using gdstk instead as gdstk is much better in handling large data and much faster in dealing with memory than klayout.

Are we talking about the PCell implementation of klayout here or the general API? The general implementation in klayout imo, is rocksolid. We did our larges tapeout, yet, in kfactory without any issue. Though that is photonics and not electronics.

If we are talking the user interface PCells... Yeah, those aren't intended for large layouts and cause lots of overhead. Shouldn't affect a switch to a klayout backend though.

[atorkmabrains]

@sebastian-goeldi Our tests are on layouts that has from 1 million to 50 million polygons shows that the loading speed for gdstk and doing a simple AND operation is much faster than klayout. Again, we develop all our DRC on klayout because gdsfactory doesn't provide similar functionality. gdstk is very good to do basic manipulation and hierarchical data. Also, gdstk has this "RawCell" concept that allow even further optimization into speed and memory conception. gdsfactory doesn't add a lot of data for each polygon on top of what is in the main backend tool. Which makes it perfect solution for optimized layout handling for us.

@proppy The main driving reason for using gdsfactory here for PCell specifically is not the memory rather it's the advanced alignment features that gdsfactory has. Memory conception is for large layouts and not the main concern here. I only mentioned the memory here just to highlight that klayout has it's limitations as well.

[proppy]

Are we talking about the PCell implementation of klayout here or the general API?

Sorry for the lack of context, here we are talking about the implementation of gf180mcuC PCells for klayout (that allow you to draw instance of the process primitive devices within klayout UI).

Their implementation used to have no dependencies other than the built-in pya klayout API (which is readily available within klayout embedded python context), and recently started to implicitly depends on gdsfactory (now requiring installation of gdsfactory and all its dependencies in a place discoverable by Klayout embedded python interpreter)

[sebastian-goeldi]

Yes, so then a small remark. For a layout with 1-50 mio polygons, KLayout PCells are definitely the wrong choice, no matter whether you want to use gdstk or klayout. You will get retired by the time you are done. I understand that klayout is a lot slower when it comes to loading polygons etc. Afaik that is due to KLayout making sure the polygons are well behaved, which gdstk (and gdspy for that matter) ignore.

Also, when doing such a boolean, it is important to utilize the proper tools, e.g. klayout can do booleans hierarchical by using the deep shape storage. Also for XOR there are tools that can use the tiling mode in order to split the work on more workers and do it directly internally instead of having to go to ruby/python.

And finally, when using the PCells of the UI, if you have concerns about the stability, I think that might be much more related to the PCell interface rather than the actual core KLayout parts. In my previous project, I found that the PCells sometimes execute code twice (or at least used to), so that can can give you a gigantic performance hit if not properly taken care of. gdsfactory takes care of that (kinda) by caching the cell functions. This is also possible by using a klayout backend (kfactory for example does this).

[atorkmabrains]

Thanks @sebastian-goeldi .

Appreciate this summary.

[atorkmabrains]

@sebastian-goeldi and @proppy Caravel chip "Without user design" has around 1 million to 2 million polygons for diffusion and poly alone.

BTW, @sebastian-goeldi I'm not undermining Klayout at all. For me it's an amazing tool. An it's the open source tool of choice for editing and viewing layouts. But when it comes to DRC/LVS and other heavy batch processing jobs like layer manipulation, basic pcell generation, ease of automation for layout, I think gdsfactory wins in that space.

[proppy]

Caravel chip "Without user design" has around 1 million to 2 million polygons for diffusion and poly alone.

And what is average number of polygons for the gf180 primitives instantiated by the PCells we've been discussing here?

[atorkmabrains]

@proppy It's very low (20 to 100 polygons). That's not the problem. Again, the main driving factor here is the advanced relative layout functionality that comes with gdsfactory.

[sebastian-goeldi]

No worries. I know that the klayout API seems not super user friendly when coming from a python world. I just got it a lot that "klayout is so complicated". And I understand where the people are coming from, but I disagree. It has a steeper learning curve, but once there, I personally like it so much more (and the people that I know that invested the time to learn it a bit as well). I don't want to create a new cell every time just for a boolean (especially in photonics) for example, which is the case in gdstk/gdspy.

And I think overall, kfactory aims to do the same thing as gdsfactory when it comes to usability and features. So, you wouldn't need to load everything in the layout, you can just hook into the layout, or at works copy on a C++ level from one layout to another (whichever is preferable).

[atorkmabrains]

On side note, @sebastian-goeldi we are working with @klayoutmatthias to optimize the performance of klayout DRC/LVS engine. We have done and advanced profiling for the klayout C++ core code and issues that we will open source soon to understand the the bottlenecks in klayout.

Thanks to @klayoutmatthias, he helped a lot optimizing our DRC code for large layouts.

Just FYI, I have digged in klayout C++ deeply, I understand how it works in and out specially for DRC/LVS side.

[klayoutmatthias]

@atorkmabrains It's good news you understand the C++ code! That means 1.) It is comprehensible 2.) You can explain it to me Nope, sorry. Just kidding on 2.) :)

Matthias

P.S. do you plan to attend FSiC2023 in Paris?

[klayoutmatthias]

Yes, so then a small remark. For a layout with 1-50 mio polygons, KLayout PCells are definitely the wrong choice, no matter whether you want to use gdstk or klayout. You will get retired by the time you are done. I understand that klayout is a lot slower when it comes to loading polygons etc. Afaik that is due to KLayout making sure the polygons are well behaved, which gdstk (and gdspy for that matter) ignore.

Also, when doing such a boolean, it is important to utilize the proper tools, e.g. klayout can do booleans hierarchical by using the deep shape storage. Also for XOR there are tools that can use the tiling mode in order to split the work on more workers and do it directly internally instead of having to go to ruby/python.

And finally, when using the PCells of the UI, if you have concerns about the stability, I think that might be much more related to the PCell interface rather than the actual core KLayout parts. In my previous project, I found that the PCells sometimes execute code twice (or at least used to), so that can can give you a gigantic performance hit if not properly taken care of. gdsfactory takes care of that (kinda) by caching the cell functions. This is also possible by using a klayout backend (kfactory for example does this).

There is no specific measure to make sure polygons are well-behaving. The only compromise KLayout makes is to create a copy of the polygons that go into the target layout. If you're talking about Python-generated layout, it's for sure unrealistic to have 1-50meg polygons generated by Python. C++ PCells are possible which may be able to generate such big things, but in general PCells are not the right place to put elaborate algorithms into. That is the domain of generators which produce ready-to-integrate and verified hard macros such as the OpenRAM generator.

For fun this creates a C++ PCell (Basic library) with something like 1..2M polygons:

ly = pya.CellView.active().layout()
top_cell = ly.top_cell()

text = []
for l in range(0, 1000):
  line = ""
  for t in range(0, 125):
    line += "%07d " % (t + 125 * l)
  text.append(line)
text = "\\n".join(text)

long_text = ly.create_cell("TEXT", "Basic", { "text": text, "layer": pya.LayerInfo(1, 0) })
top_cell.insert(pya.CellInstArray(long_text.cell_index(), pya.Trans()))

It executes in a few seconds in my case (only a very small portion shown):

[atorkmabrains]

@atorkmabrains It's good news you understand the C++ code! That means 1.) It is comprehensible 2.) You can explain it to me Nope, sorry. Just kidding on 2.) :)

Matthias

P.S. do you plan to attend FSiC2023 in Paris?

A little bit rusty, but it's there. The last time I coded serious C++ was about 12 years back, LOL.

Unfortunately, I was hoping to attend the conference. But I can't may be next year.

[atorkmabrains]

Yes, so then a small remark. For a layout with 1-50 mio polygons, KLayout PCells are definitely the wrong choice, no matter whether you want to use gdstk or klayout. You will get retired by the time you are done. I understand that klayout is a lot slower when it comes to loading polygons etc. Afaik that is due to KLayout making sure the polygons are well behaved, which gdstk (and gdspy for that matter) ignore. Also, when doing such a boolean, it is important to utilize the proper tools, e.g. klayout can do booleans hierarchical by using the deep shape storage. Also for XOR there are tools that can use the tiling mode in order to split the work on more workers and do it directly internally instead of having to go to ruby/python. And finally, when using the PCells of the UI, if you have concerns about the stability, I think that might be much more related to the PCell interface rather than the actual core KLayout parts. In my previous project, I found that the PCells sometimes execute code twice (or at least used to), so that can can give you a gigantic performance hit if not properly taken care of. gdsfactory takes care of that (kinda) by caching the cell functions. This is also possible by using a klayout backend (kfactory for example does this).

There is no specific measure to make sure polygons are well-behaving. The only compromise KLayout makes is to create a copy of the polygons that go into the target layout. If you're talking about Python-generated layout, it's for sure unrealistic to have 1-50meg polygons generated by Python. C++ PCells are possible which may be able to generate such big things, but in general PCells are not the right place to put elaborate algorithms into. That is the domain of generators which produce ready-to-integrate and verified hard macros such as the OpenRAM generator.

For fun this creates a C++ PCell (Basic library) with something like 1..2M polygons:

ly = pya.CellView.active().layout()
top_cell = ly.top_cell()

text = []
for l in range(0, 1000):
  line = ""
  for t in range(0, 125):
    line += "%07d " % (t + 125 * l)
  text.append(line)
text = "\\n".join(text)

long_text = ly.create_cell("TEXT", "Basic", { "text": text, "layer": pya.LayerInfo(1, 0) })
top_cell.insert(pya.CellInstArray(long_text.cell_index(), pya.Trans()))

It executes in a few seconds in my case (only a very small portion shown):

Nice, but I think for pcells the main reason, we moved to gdsfactory was relative object functionality and ease of access to such functionality in gdsfactory.

[klayoutmatthias]

@sebastian-goeldi Our tests are on layouts that has from 1 million to 50 million polygons shows that the loading speed for gdstk and doing a simple AND operation is much faster than klayout. Again, we develop all our DRC on klayout because gdsfactory doesn't provide similar functionality. gdstk is very good to do basic manipulation and hierarchical data. Also, gdstk has this "RawCell" concept that allow even further optimization into speed and memory conception. gdsfactory doesn't add a lot of data for each polygon on top of what is in the main backend tool. Which makes it perfect solution for optimized layout handling for us.

@proppy The main driving reason for using gdsfactory here for PCell specifically is not the memory rather it's the advanced alignment features that gdsfactory has. Memory conception is for large layouts and not the main concern here. I only mentioned the memory here just to highlight that klayout has it's limitations as well.

And finally without intending to fuel this discussion more than necessary: performance is always relative. Give me a benchmark and I'll be happy to accept the challenge. KLayout's booleans are not always on the level of boost.polygon for example, but I know how to optimize them (which I can't claim on boost.polygon) and they are all-angle robust which for me is a very important feature.

I am myself using KLayout on a daily basis on very large layouts - we're not using GDS anymore, but OASIS. I am talking about full mask layouts with literally billions of polygons. Working with such layouts - for example density calculations, booleans or DRC is not snappy, but with enough CPU power quite manageable. However, you need to be careful to choose the right ways like tiling mode for flat data or deep mode for hierarchical data. You also need to have some understanding of the basic functionality to be able to optimize which BTW is also the case for the $$$ commercial alternatives. In contrast to the vendor tools, I did not spend much time in optimizing yet, but - again - drop me a benchmark and let me help. In most cases, there a low hanging fruits that improve performance by orders of magnitude sometimes.

And commenting on the PCells for devices: the true value of such an implementation does not lie in performance or actual code, but to provide a reference design for devices with appropriate parameters, their physical outline and - most importantly - the correlation with the models. To me it does not matter at all what tool the device primitives are implemented in. But it is very important that the implementation can act as a blueprint (i.e. is readable, comprehensible and executable) for other implementations, supplying the model to hardware correlation. In the end it's not realistic that every user of the devices uses the same single implementation - to attract a broad user community, you need to serve many kind of platforms. The goal should be to have a description of the polygons I need to draw in order to generate a device with predictable properties. If that is executable code, the better - whatever system you deploy that to, as long it is open source.

Matthias

[atorkmabrains]

As always @klayoutmatthias, perfectly said. Can't agree more. You're always helpful. Your insights on the performance were always helpful to my team.

[atorkmabrains]

@proppy Here is my recommendation:

• Keep the current implementation using gdsfactory.
• Document the need to add gdsfactory in the installation for PDK requirement.
• Make sure to clean up the temporary file generated after reading in klayout.

If you agreed with that direction, please confirm. If not, please let me know what is the direction that you want us to follow?

[proppy]

In the end it's not realistic that every user of the devices uses the same single implementation - to attract a broad user community, you need to serve many kind of platforms.

That's aligned with my thinking as well, to me the implementation of the PCell should have a strong affinity with the audience of the environment it is deployed on. If running inside Klayout it makes sense to target Klayout pya API so that Klayout community can easily read, learn from, troubleshoot, and contribute to them.

It also makes sense to have another gdsfactory implementation of the PCells, targeted to the gdsfactory community that want to draw layout programmatically outside of klayout using gdsfactory constructs.

We can always have test suites that verify the conformity of drawn devices with the PDK primitive specifications.

[proppy]

• Keep the current implementation using gdsfactory.
• Document the need to add gdsfactory in the installation for PDK requirement.
• Make sure to clean up the temporary file generated after reading in klayout.

I'd love to get @mithro input there, but I don't think this path is desirable.

While I think it's important to have a gdsfactory version of the PCells, using them for klayout creates significant environment and cognitive burden on the target audience: the klayout community:

• klayout has its own embedded python environment, it's standalone and doesn't require you to have python installed on your host
• gdsfactory comes with ~350M of transitive dependencies
• as commented in https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/issues/28#issuecomment-1449588108 the current implementation is not "simple" and involve multiple roundtrip between disk and different memory respresentation of the same PCells.

Another observation: pya is the documented and idiomatic way for implementing PCells in klayout; if the primary argument for ont using pya is the lack of "advanced relative layout and alignment functionality" and we all agree that this is important for implementing PCells: I'm sure @klayoutmatthias would love to get a feature request filed that document the missing functionalities in the pya API surface. We can all help adding those primitive to klayout python API and make its ecosystem better.