Curvilinear OASIS format

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

  • edited November 23

    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.

  • edited November 21

    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

Sign In or Register to comment.