It looks like you're new here. If you want to get involved, click one of these buttons!
The curvilinear OASIS format may happen in future due to the increasing demands of Curvilinear GDS shapes for better Litho performance.
One can refer to this SPIE paper: 'Status of Curvilinear data format working group' 2022, doi: 10.1117/12.2641557.
Previous from GDS to OASIS, now seems this new Curvi-OASIS.
Those papers mentioned about different ways to present a curvilinear polygon:
Such as piece wise linear (current or conventional ?),
or Quadratic Bezier curve fitting or spline fitting which needs or records the control points in GDS to represent a polygon.
The new curve fitting format may reduce points needed thus leads to less file size.
Wondering might this be of interests to Klayout developments?
Comments
https://semiengineering.com/the-quest-for-curvilinear-photomasks/
https://www.semanticscholar.org/paper/File-formats-for-curvilinear-multi-beam-writing-of-Zillner-Moqanaki/0678e866e9b2f916b265e5491a0fff16d6f9e3e6
This paper abstract:
The semiconductor industry's migration to EUV for the leading-edge nodes provides significant advantages and poses new challenges for the mask writers. The mask quality requirements for the leading-edge process technology call for ILT (Inverse Lithography Technology) and curvilinear patterns to improve the attainable resolution on wafers and extend the process windows. While single-beam writers cannot handle writing arbitrary curvilinear patterns without throughput penalty, multi-beam mask writers (MBMW) can easily print such patterns without degrading their throughput5,6. However, the transition to the curvilinear mask ILT significantly increases the layout complexity, posing a challenge for data transfer and storage systems as the file sizes increase substantially1. Traditionally, multi-beam-writers have been using a mask data input format derived from OASIS P44, namely OASIS.MBW 1.0/1.2, leading to multi-terabyte layouts. We present OASIS.MBW 2.1 as an efficient data format for curvilinear ILT masks. OASIS.MBW 2.1 enables a dramatic reduction in file size and vertex-density and preserves the qualities of OASIS.MBW 1.1/1.2 as well as quick and easy adaptability for the end-users. This is achieved by allowing the use of the OASIS P39 POLYGON RECORD in addition to the other OASIS.MBW 1.x properties, creating a hybrid format between OASIS P39 and P44 that provides a minimal file size comparable to OASIS P39 for pre- and post-fracture data operations at the fabs. Consequently, OASIS.MBW 2.1 provides the optimal combination of minimized file size and minimized required CPU time, thus enabling fast processing as well as a fast transfer for all applications.
Sure, that's of interest!
DXF has a way to specify parts of curves as rational or non-rational B-splines. It does not look much like the sketch above, but I'm lacking details of the OASIS proposal. I don't have access to SPIE papers and I can only implement features that are publicly documented and for which there are test cases. Under these conditions, I'll be happy to implement them.
Yet, don't expect such shapes to be represented in their natural way inside KLayout's database. They will be converted into piecewise linear polygons (maybe like in DXF with a configurable accuracy) on reading. None of the algorithms inside KLayout can handle curvilinear features as of now. A natural representation will need much more development, specifically when editing is required.
I'd also request some level of compatibility with DXF for the synergy effect here.
Matthias
Thanks Matthias for the info and comments,
I see, it definitely would need massive efforts like from GDS to OASIS, or maybe even not practical.
The AutoCAD area do utilize much of Bezier and B-spline curves to represent objects. Just wondering if the mask industry would try DXF for the curvilinear shapes at least as some kind of intermediate buffer format, not very familiar with DXF, maybe this is just naive thinking.
The tricky thing is, unlike conventional GDS and OASIS, the SEMI standard for this curvilinear-compatible new format is not ready yet (based on those papers).
I just raise this topic and hope more open-source info would be capturable after the standard evolves to a mature statues and industry reaches agreement on that and adopt it.
All these depends on the adoption extent of curvilinear shapes for advanced masks. Again, from the papers they seem confident to bring it to reality in the future.
Let's see - I am in touch with some people about this. It's all about how open SEMI is and how willing they are to collaborate with Open Source.
DXF IMHO does not qualify for mask data transfer as it does not even have a concept of "inside" and "outside". So data quality is difficult to achieve. On the other hand it is frequently used to generate curved features as AFAIK there are no VLSI tools which really support such things. Curved features are a speciality of HV power, MEMs or photonics devices and not mainstream logic design driven. I doubt somewhat that these features will see a broad reception.
Also I cannot imagine efficient computation geometry algorithms operating directly on these features. They will need to approximate curved features by piecewise linear polygons at some point in the processing chain. I think the main reason for having curved features in stream formats is to have this translation done at the latest moment possible. This provides some justification, but not a very strong one.
Matthias
Yeah, many challenges there for sure. might be an extension but not replacement to current OASIS.
Maybe just an intermediate format used to shrink the file size.
In this website they had this survey,
showing the current adoption and future predictions of curvilinear mask (features).
'10th Annual eBeam Initiative Survey Reports Photomask Market Optimism'
I see ... thanks for the link! I'll stay optimistic
can multigon format implemented in klayout according to the semi p44 standard?
Geometrical algorithms (such as 2D booleans) operating directly on curved shapes are available in open source code (i.e. OpenCascade) but are much less efficient (slower) than the algorithms operating on polygonal shapes.
One possible way to make accurate booleans on selected curved shapes without loosing the capability of processing large circuits is to use both representations (gdsii and dxf).
I have followed this strategy in my layoutDD project. In a new project I am usually importing a gdsii file and a dxf file which describe the same circuit. In a selected small region (enclosed by a polygon) it is then possible to generate precise 3D shapes using the curved shapes defined in the dxf file and the "inside" and "outside" information defined in the gdsii file.
Hi @cyrustabery,
is multigon support out already in OASIS? The last time I got notice of that extension, it was still under discussion.
Basically @wsteffe is right. Internally I would always revert to polygon formats, but like DXF the reader should accept the geometry specs and internally convert it to polygons.
So the answer to "can it is be implemented" is "yes", but the answer to "will it be implemented" is not necessarily a "yes" as well.
The reason is in the closed nature of the OASIS specification. I am willing to collaborate with the OASIS task force, but on an open-source friendly basis. By this I mean, that I get permission to implement the standard. As an open source implementation can be considered a disclosure of the specification, there are legal concerns from my side, if this permission is not given.
Also, test data is needed to verify the implementation. This is my second requirement.
Matthias
Hi Matthias,
This is the official post for the multigon specs. https://store-us.semi.org/products/p04900-semi-p49-specification-for-experimental-curvilinear-multigon-extension-to-semi-p39
BR
Homero
Dear all,
There is some development: I got in touch with people who want to clarify if the spec can be implemented in Open Source. If we're lucky, we can settle the legal issue and go into a first implementation.
Matthias