KLayout
Add Support for Raith MBMS Paths
There is no such things as RaithPXXData in GDS, so I’m assuming that you’re using gds properties to add this info, right ? Instead of screenshots of the data, could you just attach the two small gds ?
And what is “add support” supposed to mean ? Be able to edit the property ? Or should the drawing of the path be changed depending on this data ?
What exactly is that?
I recall someone requested Raith something support once. But I could not get a clear statement if that is a standard feature (if not: what qualifies proprietary extension for implementation in an open source tool) and also about the IP situation (the feature may be patented).
Is there an open specification? And what exactly is that extension about? I understand that maybe that is a periodic placement of a cell along a path.
Matthias
There is no such things as RaithPXXData in GDS, so I’m assuming that you’re using gds properties to add this info, right ? Instead of screenshots of the data, could you just attach the two small gds ?
And what is “add support” supposed to mean ? Be able to edit the property ? Or should the drawing of the path be changed depending on this data ?
I am aware that this is not part of the GDSII spec, it is an extension "created" by Raith for Moving Beam Moving Stage lithography.
What i ideally need is just to be able to read, write and edit the "RaithPXXData" in a Path object in the python package (everything that has been implemented in gdstk). So I can use this with gdsfactory. Having some kind of interface in the KLayout application is not necessary, but a plus.
What exactly is that?
I recall someone requested Raith something support once. But I could not get a clear statement if that is a standard feature (if not: what qualifies proprietary extension for implementation in an open source tool) and also about the IP situation (the feature may be patented).
Is there an open specification? And what exactly is that extension about? I understand that maybe that is a periodic placement of a cell along a path.
Matthias
Yes it is about placing a cell along a path with x and y spacing to create a "grid". I hope the comment above answers your other questions
Hi @MatthewMckee4,
I understand your request, but I don't like to implement proprietary extensions just because they are there.
I believe that Open Source should be a give-and-take. If there was support for this extension, that would create a benefit for that company, and it should be balanced by some contribution. For example, they might donate their specification to the public domain.
If there is a public document somewhere - issued by Raith - describing the extension and explicitly permitting 3rd party implementations, I will be happy to implement it.
Otherwise, I don't like to include it. The Semiconductor business is well known for their habit of protecting IP, and patent infringement by Open Source is a serious matter. Plus, I don't want to create a benefit for a specific player without a return to the community.
In other cases, I have implemented proprietary extensions, but without making the sources public. This way, there is no risk of disclosing protected IP and I can withdraw the implementation if needed. A GDS extension is an integral part of the GDS reader, so it cannot be closed source.
Matthias
Hi @klayoutmatthias,
thanks for this response, I realise now that my "issue" made it seem like i was asking for all of the work to be done, so i would like to amend it and say i am more than happy to implement this all myself, if you could help me in pointing me in the right direction that would be greatly appreciated. I have given myself some time to look around this code in this repository, but as it is so large i find myself lost. I understand that the python interface file is at src/pymod/distutils_src/klayout/dbcore.pyi but im unsure where the related c++ files are, like the Path class and the read and write functionality. If you could direct me to these files and the best way for me to introduce these new changes that would be amazing.
As previously mentioned, this was already implemented in gdstk, by myself, so i have a good idea of how i would like to implement it in klayout.
If there is a public document somewhere - issued by Raith - describing the extension and explicitly permitting 3rd party implementations, I will be happy to implement it.
Unfortunately they haven't provided us with much information (only what i have already shown above)
Matthew
Thanks for this offer, but honestly, if you implement it yourself, that does not change much. The legal issue persists, unless you want to keep it entirely private to you - but that is not my understanding of open source either.
You mean you're in touch with the Raith people? I am not against talking to them if the like.
Matthias
There is "write Raith gds from Matlab" code on GitHub, licensed under MPL2.0 aka Mozilla Public License. https://raith-gdsii.readthedocs.io/en/latest/index.html They not just use properties, they extend gds by using "unused" cmd codes and invent a 4 byte float. https://raith-gdsii.readthedocs.io/en/latest/Raith_library.html#id6 So "Raith gds" is not compatible with tools only reading "regular gds".
Sorry i haven't gotten back to you, we are speaking to our Raith contact currently.
There is "write Raith gds from Matlab" code on GitHub, licensed under MPL2.0 aka Mozilla Public License. https://raith-gdsii.readthedocs.io/en/latest/index.html They not just use properties, they extend gds by using "unused" cmd codes and invent a 4 byte float. https://raith-gdsii.readthedocs.io/en/latest/Raith_library.html#id6 So "Raith gds" is not compatible with tools only reading "regular gds".
Yes, it is exactly an extention:
The have added new cmd codes that cannot currently be read
Having code that writes the format is not a public specification. I don't see that the author is associated with them and the comments are not encouraging - to me it looks like Raith invented their own flavor of GDS. That is not something that should go into public domain code.
I will try some research on my own.
Matthias