allow usage in klayout embedded python

[proppy]

Would re-using kfactory component model when implementing klayout pcells for interactive usage (inside klayout gui) be within the scope of the project?

Context is the discussion about a recent refactoring of open source PDKs pcells in efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr#28

A few question toward this:

• does kfactory aim to feature parity with gdsfactory drawing primitive (rectangle, boolean ops, etc)
• would KCell just work on top of pya instead of klayout.db/lay

  kfactory/src/kfactory/__init__.py

  Lines 6 to 7 in 1bcdc79

  	import klayout.dbcore as kdb
  	import klayout.lay as lay

• would it makes sense to package an lite version of kfactory with less dependencies (no yaml, no scipy)

Let me know what you think!

[sebastian-goeldi]

I think it is within the scope that we can make this happen. I think the main issue being the imports. But I can see that with the following solution:

try:
    import klayout.dbcore as kdb
    import klayout.lay as lay
except ImportError:
    logger.warning("Cannot find klayout modules dbcore and lay, trying to import klayout packages")
else:
    import pya as kdb
    import pya as lay

does kfactory aim to feature parity with gdsfactory drawing primitive (rectangle, boolean ops, etc)
Kind of yes. But they are a bit more "advanced" as in they are built-in to klayout directly. (In the following assume c (and c1, c2,...) is an instance of kf.KCell and layer_index is either a kf.LayerEnum or int)

• rectangle:

  c.shapes(layer_index).insert(kf.kdb.Box(left, bottom, right, top)```

• booleans:
  I would argue klayout booleans are just straight up better than gdsfactory booleans

  region = kf.kdb.Region(c1.begin_shapes_rec(layer_index)) # get all shapes (recursively from cell c1)
  region2 = kf.kdb.Region()
  region2.insert(kf.kdb.Box(0, 500, 1000, -500))
  # can do this an arbitrary amount of times
  
  # boolean operations
  sub_region = region - region2 # r NOT r2
  add_region = region + region2 # r OR r2
  and_region = region & region2 # r AND r2
  xor_region = region ^ region2 # r XOR r2

would KCell just work on top of pya instead of klayout.db/lay

Yes, pya contains both and more (such as Qt objects)

would it makes sense to package an lite version of kfactory with less dependencies (no yaml, no scipy)

We can do that. scipy purely a requirement for some pcells, e.g. the euler bends depend on it, so if those are stripped out, no problem at all to remove the scipy. As for yaml, I guess so. The thing you lose there is the placer and yaml <-> KCell, but I think for a GUI flow that would be an edge case at best anyway.

[joamatab]

we are in the process of evaluation kfactory as the backend for gdsfactory

gdsfactory/gdsfactory#1031

Now that kfactory supports complex cells we could fully support all gdsfactory features

[sebastian-goeldi]

@proppy is this still something you'd be interested in? I think we could implement a stripped down version kfactory for this, but I think with the current dependencies, some of then deeply rooted in the code, I won't be able to support a simply try/except import of klayout/pya

I'd also be interested in helping make klayout more portable i.e. having it compiled against conda envs, so that on all platforms a conda env would be able to install the GUI from a conda channel like you did already for one platform

[joamatab]

@mabrains
@atork
@proppy

[proppy]

@sebastian-goeldi, sorry for the late follow-up.

I think @atorkmabrains would definitly be interested to use something like this for:
https://github.com/mabrains/sky130_klayout_pdk
and
https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pv

[proppy]

I'd also be interested in helping make klayout more portable i.e. having it compiled against conda envs

for conda-env, we already maintain some conda packages for klayout (w/ GUI) in this channel:
https://anaconda.org/LiteX-Hub/klayout/files

It would be nice to have them part of conda-forge as well, there was some work done toward that in:
conda-forge/staged-recipes#22419
conda-forge/staged-recipes#20396
conda-forge/staged-recipes#20475
conda-forge/staged-recipes#21131

[sebastian-goeldi]

@proppy I think this is at the moment not realistic, a big part of kfactory depends on pydantic and it's at least at the moment evolving too fast to request klayout to keep pace with that on the windows builds. So for this to work, I think we would still need a conda installation method at the very least for windows, which is not great, but possible. We could make use of the 0.28.13 addition of git+https:// support and host a separate saltmine on a github projects gitthub.io page (which transparently includes the standard saltmine as well) and then offer kfactory on that saltmine.

I think that would be the most reasonable approach.

[proppy]

at the moment evolving too fast

you mean evolving in backward incompatible way? I would have to assume that in order to be "embedded" in klayout built-in python environment, one would have to bundle all the dependencies in the klayout salt package.