The KLayout LVS tests should be run using GitHub Actions

[mithro]

The KLayout LVS tests found at https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/tree/main/rules/klayout/lvs should be run using GitHub Actions.

[atorkmabrains]

@mithro, @mohanad0mohamed is currently working on it.

[mithro]

We should probably use the KLayout distributed using PyPi for this.

[mithro]

See comments at #8 (comment) and #8 (comment)

[mithro]

FYi - @proppy / @joamatab

[atorkmabrains]

@mithro Klayout LVS doesn't work from Klayout Python package. All verification code in Klayout is strictly Ruby and their is not representation in Python.

[proppy]

@atorkmabrains are you talking about the possibility of:
a/ implementing new LVS/DRC checks in python
b/ triggering existing LVS/DRC check (written in Ruby) from the PyPI klayout package.

while a/ is interesting my understanding is that only b/ would be required for this particular issue?

[atorkmabrains]

Hi @proppy ,

For a, Klayout doesn't have python implementation for LVS/DRC. It's only based on Ruby. We would have implemented it in Python if there was one.

For b, I'm not sure if that's feasible and I don't think it is. The only way that we know triggers LVS/DRC run is by using the command line: Klayout -b .....

We have written a python script the prepare the correct command line options and we are currently working on a parallel version that would run much faster than the current version.

[atorkmabrains]

@proppy Here is the link to the DRC/LVS scripts respectively:

• https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/drc/run_drc.py
• https://github.com/google/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/rules/klayout/lvs/run_lvs.py

[proppy]

@atorkmabrains there is a new version of the klayout python package in the work (KLayout/klayout#1082) that include the layout and the macro engine.

I gave it a try here: https://colab.research.google.com/gist/proppy/6956a38ce1a69c710719c7edb40377c6/klayout-playground.ipynb#scrollTo=yiyyIZYbYTSH but it looks like it doesn't include the ruby/lym interpreter nor the high level DRC module (which is also implemented in ruby https://github.com/KLayout/klayout/blob/7a5737d55fa04f641ee20f94f706f89a1ee43a2b/src/drc/drc/built-in-macros/_drc_engine.rb as you commented in #4 (comment)).

I'm curious if @klayoutmatthias is also planning to include gsi/rba/drc/lvs in the PyPI klayout package in the near future? Or if that would be out of scope (it kinda get in a scary territory as we nest interpreter context "just for the convenience" of being able to make structured call from python).

[atorkmabrains]

@proppy That's really nice. I didn't know that @klayoutmatthias was working on this. Seems really nice.
BTW Matthias has mentioned that their is no intention for him to support DRC using python:

https://www.klayout.de/forum/discussion/1402/support-drc-using-python

I think he might change his mind with the effort you guys are doing with him.

BTW, it's not a think interface as mentioned in the link above. It have some functional code. I have reviewed the ruby.

[proppy]

BTW Matthias has mentioned that their is no intention for him to support DRC using python:

That's slightly different in my opinion (i.e the a/ mentioned in #4 (comment)), here we're only talking about b/ (launching existing ruby's DRC check from klayout python package).

[atorkmabrains]

Ah, I see. that's what we do in run_drc.py and run_lvs.py

[proppy]

Ah, I see. that's what we do in run_drc.py and run_lvs.py

Yes, exactly! And I think @mithro was saying in #4 (comment) that it would be nice to be able to use the PyPI for that instead of the full featured klayout binary.

[klayoutmatthias]

Well .. I'm not refusing, but it's simply a double effort. Point is: The DRC language is basically just syntactic sugar. Ruby does not really play a role in standard DRC decks - i.e. such consisting only of input, output and check statements. Only if you utilize conditionals, loops or monkey-patch classes it becomes Ruby'ish. Porting the thing to Python is not impossible. Basically Ruby/DRC is a wrapper around some objects like Region, Edges, EdgePairs, Texts etc. The same can be done in Python. KLayout plays a Ruby trick (instance_eval) to run a Ruby script in a different context. I don't know if that is possible in Python, but given the PyPI klayout module plus some hypothetical "klayout_drc" extension you may come up with an implementation that allows this form of DRC deck: from klayout_drc import * # Similar to Ruby DRC from here, except for loops, conditionals, units ... source("input.gds") report("report.lyrdb") metal1 = input(15, 0) metal1.width(0.25).output("M1 width >= 0.25") ... I don't think Python allows you to patch the float and integer classes to allow something like "0.25.um" or "250.nm", but that is optional anyway if you use micron units consistently. The effort for implementing this is not small (the Ruby code is ~7k LOC, not counting the comments), but should be straightforward. Still I don't want to do that myself as it is a replication and duplicate maintenance effort. But it is open to everyone to supply (and support) such a "klayout_drc" module. Outlook: I am slightly worried about the possible evolution of different standards - one for external and one for application-internal use. In the end we may want a coding-language independent format (e.g. YAML) and read+compile the DRC deck from there - in this case without the Ruby or Python low-level access option. Such a project could target other DRC engines too and was the great unification DRC authors look for. I sensed there is interest in such a project and that is a path I'd like to follow myself rather than supporting pythonification of the DRC decks. Matthias

…

On 28.07.22 09:03, Johan Euphrosine wrote: BTW Matthias has mentioned that their is no intention for him to support DRC using python: That's slightly different in my opinion (i.e the a/ mentioned in #4 (comment) <#4 (comment)>), here we're only talking about b/ (launching existing ruby's DRC check from klayout python package). — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGEHQCKOZAQFSIYVV5WA2WDVWIWCTANCNFSM54FSPH5A>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[proppy]

@klayoutmatthias thanks for taking the time to lay out (no pun intended) your thoughts, I think having a standard DRC language would be a great step for the ecosystem and IIRC @RTimothyEdwards (from magic VLSI) suggested that the small DSL/expression based subset you demonstrated at FSiC could be a good foundation?

In this particular issue, we weren't really after re-writing DRC rules in Python but rather discussing if the existing interpreter for the pseudo-Ruby rules could be included in the PyPi wheel to allow them to be triggered from the Python API.

[klayoutmatthias]

Yes, I recall the discussion with Tim :)

I personally think integrating Ruby into a Python module (if this is what you mean) will be difficult. Basically Ruby is just another library to link against, but it takes control over the stack for implementing the garbage collector and I think interference cannot be avoided. However, my experiences date back to Ruby 1.8.

Matthias