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 5805c8f

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