![\"\"](\"https:\/\/www.newsbeep.com\/ie\/wp-content\/uploads\/2026\/05\/Screenshot-2026-05-20-at-4.26.13-PM.png\")
L-R: D2S\u2019 Fujimura; Micron\u2019s Scheid; HJL\u2019s Levinson; Synopsys\u2019 Fenger<\/p>\n
SE: As curvilinear masks become more mainstream, what parts of the ecosystem around them need to evolve to make them viable at scale?<\/p>\n
Fenger:\u00a0The entire mask data prep flow needs to become curvilinear-native, and if curvilinear is being used in design, then even the upstream design tools need to become curvilinear-native. Bolting curvilinear onto polygon-based plumbing just doesn\u2019t work. Across the industry, there\u2019s been a lot of rework of tools to support curvilinear-native formats. Apart from that, the use of cloud and HPC, such as GPU, becomes more and more important in terms of compute scalability, and people are looking at the ability to do caching and only recompute what has changed when you do mask re-spins. This is because, at the moment, curvilinear is more expensive to compute. ILT, fracture, and those steps become more and more expensive. That said, ILT is natively curvilinear. And with MBW, there would be no need to add a \u2018Manhattanization\u2019 step to make those curvy shapes manufacturable \u2013 simplifying the process. We need to leverage the most powerful compute available to keep TAT manageable, such as a GPU, and we need to be clever in what we\u2019re doing. We don\u2019t necessarily need to recompute everything if it\u2019s not needed.<\/p>\n
Another aspect is the inspection ecosystem. We need to go from finding everything to finding what matters. As Aki mentioned, being able to have a mask manufactured as intended is possible with curvilinear. What does that mean in terms of how we inspect the mask or how we do mask metrology? With a Manhattan mask, we assume there are going to be errors, but for curvilinear masks there\u2019s potential to drive errors to zero. Do we hold mask manufacturing to that rule, that we can achieve no errors? Do we need to consider mask variability simulations inside our ILT engine so that the ILT engine avoids mask structures that have poor dose margin or higher variability? We can see what\u2019s possible in the future if we have a perfect mask. That\u2019s a feasible concept, but today we\u2019ve always assumed the mask is going to have errors. Is that good enough? Can we do better than that?<\/p>\n
Levinson:\u00a0The place where I have the biggest concern right now is defect inspection. When we jump to high-NA EUV, what becomes printable is exceedingly small. The eBeam Initiative survey showed the luminaries saying it\u2019s under 15-nanometer features in terms of printability concern. That\u2019s a very small feature. We solve resolution with EUV by doing at-wavelength inspection. The very short wavelength gives us potential for very high resolution, and that has definitely given us a lot of benefit. But as we go up to high-NA, we need higher-resolution EUV inspection, and this is where some subtleties come in. We also need good contrast between the defects and the background, the multilayers, which are highly reflective. The problem is that the reflectivity of the multilayer falls off when you go to larger angles away from normal, and it\u2019s those larger angles that give you the higher resolution. We can make higher-resolution optics at EUV wavelengths, but we can\u2019t fully benefit from that higher resolution because we don\u2019t get good image contrast for the higher spatial frequency components.<\/p>\n
If we continue the route of actinic inspection, we\u2019re going to have to find a clever way to get around this fundamental physics. Alternatively, people look to electron beams, but that has a major throughput issue, and there\u2019s a lot of work ongoing to try to do multi-beam inspection tools. They\u2019ve achieved some success there, but it\u2019s a difficult problem. When we do multi-beam mask writing, we take all these electrons and put them down onto the resist on the mask, and the job is done. Each electron has done what it needs to, whereas in inspection you\u2019re looking at electrons coming back from each one of those beams, and you need to separate out the signals from the different beams. It\u2019s a very hard problem in electron beam technology. I have a lot of concern about defect inspection going forward. There are big challenges both using EUV for inspection and using electron beams.<\/p>\n
Fujimura:\u00a0We touched on most of the issues, like metrology and data. One thing I wanted to add about ILT is that the amount of time it takes to output a curvilinear shape is actually less than what it takes to do Manhattan shapes. The reason is that ILT, across every software vendor, is fundamentally mathematically computed using Fourier transforms in the pixel domain. The output is inherently curvilinear to begin with. In order to make it work for what used to be VSB masks and the infrastructure that\u2019s more suited to Manhattan designs today, there\u2019s a post-process step that rectifies patterns to Manhattan, and then adjusts those Manhattan patterns with a little simulation. I would posit that you can make it faster by only outputting curvilinear shapes. That\u2019s what we do at D2S.<\/p>\n
I also get the reality of the world today. Manufacturing is a very conservative world by necessity. You have to make sure you don\u2019t break anything. I say all the time that \u201cbetter is different and different is bad\u201d in production. You want something that already works; you don\u2019t want to touch it. You have to wait for the next opportunity to insert something new, because you don\u2019t want to take the chance of breaking the existing production flow, even for something substantially better. I understand there\u2019s a momentum behind keeping things the way they are.<\/p>\n
Despite that, I would say the idea of fracturing per se should not be necessary in the multi-beam world. In the VSB world, it was absolutely required, but in the multi-beam world, it\u2019s not true. You do need mask data preparation. You have to decide how it\u2019s going to replicate, where it\u2019s going to be placed, whether it\u2019s going to be rotated, scaled, or biased. There are many things that have to be done for mask data prep, but the word \u201cfracturing\u201d by itself? I don\u2019t know that it should exist in a curvilinear mask flow 10 years from now. I get that it\u2019s necessary today, but there are opportunities to improve the curvilinear data flow not just by looking at data sizes, transport, compute, or connectivity, but by doing less. Take advantage of the fact that we can make manufacturable targets and do less than we used to do before, because a lot of what we do today in the mask world shouldn\u2019t be necessary when you\u2019re producing manufacturable masks.<\/p>\n
Scheid:\u00a0I like how Aki put that, and to me it really translates to needing to be curvilinear-native throughout the mask flow, from input data coming into the mask shop in a curvilinear-native format, passing it to the multi-beam writer, and passing it to inspection tools and even metrology tools to handle that data directly without additional fracturing. That\u2019s a necessary evolution. We have the pieces there, but there are still systems that have to pull it together. The second thing I\u2019d add that I didn\u2019t hear mentioned is MRC mask rule checks. There\u2019s still a lot to be learned in terms of defining every single rule that could potentially result in a problem in mask manufacturing, whether that be resolution or inspection issues. Some of those rules are known, and there\u2019s software already that can execute MRC checks against those rules. But there are still limitations. Even when errors are detected, how do we correct those errors, after OPC has already been completed, without having to run the whole thing through OPC again? And what are all the potential issues as curvilinear patterning gets more complicated? There is still a lot to be learned.<\/p>\n
SE: Mask inspection and metrology are struggling to keep up with shrinking features and pattern complexity. What are the big gaps today, and what are companies doing to bridge them?<\/p>\n
Levinson: People are going to have to get very clever about trying to capture very small defects using EUV light, and get better performance out of the multi-beam e-beam inspection tools. On top of it all, there\u2019s a lot of activity taking place on the measurement of curvilinear features. If you take a long, skinny line and talk about the critical dimension, it\u2019s obvious to the youngest engineer what the critical dimension of that feature is. But now look at some arbitrarily drawn curvilinear feature, and the critical dimension is very far from obvious. Once you figure out what the critical dimension is, how do you define line-edge roughness? When you\u2019re talking about a straight line, you have a reference \u2014 some average, perfectly straight line. What becomes the reference when you\u2019re going to talk about line edge roughness for a curved feature? Because you\u2019re always talking about the deviation of the edge from some reference.<\/p>\n
When dealing with Manhattan geometries, you\u2019re talking about rectangles. They\u2019re something we learned about the geometry of early on. Now look at the mathematics required to describe curvilinear shapes, and you probably need a graduate degree in mathematics. It\u2019s a very big gap in terms of sophistication. There\u2019s a lot to work through. Our industry has many very bright people working on the problem, and I have full expectation we\u2019re going to see solutions. We\u2019re just in the middle of people working through them all.<\/p>\n
Fujimura: I completely agree with Harry. For metrology, there\u2019s a fairly well-established direction now \u2013 not conclusive, but a direction \u2013 which is to measure edge placement errors (EPE) along the contour. Ultimately, we\u2019re talking about masks that are physical things that either let light through, or reflect light in the case of EUV. It\u2019s the local area that matters. Whether you have 193nm wavelength light or 13.5nm wavelength EUV, you have a limit of what those wavelengths can effectively resolve. You just need to be accurate within what it can see. There\u2019s a definite spec for what the mask needs to accurately convey. The sense of accuracy is well-defined for each lithography. There needs to be some sense of a local area \u2013 a smaller local area for 13.5nm, and a bigger local area for 193nm \u2013 that defines what is sufficient accuracy. Now, if you want local area, that\u2019s kind of hard to keep track of, so it\u2019s easier to look at every contour edge and make sure they\u2019re correct. That\u2019s actually a subset of the full requirement. I don\u2019t think it\u2019s the only way you can meet what ILT or OPC simulated. After all, what we\u2019re trying to do is make the physical mask match the assumptions made in simulation during ILT. That\u2019s it.<\/p>\n
While local area is actually sufficient, where the industry is going is edge placement error and a statistics-based approach. One EPE measurement is just too uncertain because there are manufacturing variations and measurement variations. You want to take an average across many EPE measurements to get a useful metric. There are many different ways to do it, and I\u2019m sure memory makers would approach it differently from how random logic manufacturers would, but I see trends. I don\u2019t know how long it would take, maybe a couple of years, for the industry to settle on a standard approach. There are many more metrology suppliers than mask writer suppliers, so it doesn\u2019t naturally converge the way it might if it were a mask-making issue where there are only two suppliers. It will take a little time.<\/p>\n
Scheid: In the mask house, what we see today in curvilinear is still early days for what\u2019s possible. The mask shop is keeping up with the needs of wafer fab patterning, and industry roadmaps shown at BACUS include a clear path to high-NA EUV and beyond. The high-NA ecosystem was shown at BACUS a couple of years ago to be far more mature than the low-NA ecosystem was initially. A lot of progress has been made.<\/p>\n
Building on what Aki mentioned on EPE metrology, we need to figure out how to best represent the mask in a way that matters to the wafer, so we have good qualification metrics established and agreed upon with the wafer fab. We also need to understand, in the context of those metrics, how to actually feed back into and improve the mask process itself. When we\u2019re changing from more traditional metrics that we understand really well, moving to new metrics can also create a need for new control parameters so we can tune the mask process to optimize the new metric. Inspection is always pushing current equipment capability, whether that\u2019s using 193nm for EUV, or using EUV actinic, or possibly e-beam inspection at some point. And that inspection data, especially when it produces high volumes of nuisance detections, needs to be filtered through an auto-defect classification tuned to where we have high accuracy and don\u2019t require an excess of human labor and oversight. Tightening up that entire qualification flow contributes significantly to reducing turn time, which as we mentioned, has to be managed carefully on leading-edge masks.<\/p>\n
Fenger: Building on what Glenn mentioned, there is a gap in inspection in terms of the ability to predict what prints on wafer and what doesn\u2019t. We\u2019re often measuring what\u2019s easy to detect, not what changes wafer yield. Glenn also mentioned MRC rules, and I believe many MRC rules are actually being dictated by inspection. Inspection is limiting what mask manufacturers will allow to put on the mask because they can\u2019t inspect it otherwise. It\u2019s not necessarily being limited by the multi-beam writer or the mask manufacturing process. I would propose that model-based MRC is needed for some applications being able to actually simulate what the inspection tools see, and then making a decision whether this can be on-mask or not. It\u2019s far too complicated a problem to simplify into rules, at least for some layers. There needs to be more work done to move MRC in a model-based direction, and I suppose at that point we can\u2019t call it Mask Rule Checking anymore.<\/p>\n
The other topic that was brought up is how you characterize a mask. EPE is probably the most upfront solution, though I\u2019m not sure it will be the best solution, as Aki mentioned. Being able to characterize EPE, local curvature, fidelity, CDU, LWR \u2014 these are all new problems for curvilinear. How do you characterize CDU for curvilinear patterns? How do you measure CD for a curvilinear pattern? All of these things need some thought, and I\u2019m sure the mask metrology vendors will come up with good solutions.<\/p>\n
Fujimura: MRC needs to become model-based, and therefore the rule-based part of it will go away. That\u2019s a really important point.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"Key Takeaways: Curvilinear masks require native data flows across design, mask data prep, writing, inspection, and metrology. Inspection…\n","protected":false},"author":2,"featured_media":469213,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[202757,202758,167159,202759,202760,152735,202761,202762,202763,3308,61,202764,202765,60,202766,202767,202768,86994,202769,162709,202770,13156,80],"class_list":["post-469212","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology","tag-actinic-inspection","tag-curvilinear-masks","tag-d2s","tag-e-beam-inspection","tag-edge-placement-error","tag-euv","tag-gpu-accelerated-computing","tag-high-na-euv","tag-hjl-lithography","tag-hpc","tag-ie","tag-ilt","tag-inverse-lithography-technology","tag-ireland","tag-mask-inspection","tag-mask-metrology","tag-mask-rule-checks","tag-micron","tag-multi-beam-mask-writers","tag-opc","tag-photomasks","tag-synopsys","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/469212","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/comments?post=469212"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/469212\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media\/469213"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media?parent=469212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/categories?post=469212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/tags?post=469212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}