Status of the project / README

[Aypac]

Hi, I'd be interested in using a proximity correction code for a project. Finding this, I was wondering what the maturity/status of this project is. Do you think it might be used productively already? If so, it would be great if you could find the time to write a README with some very rough usage instructions.

Thank you for publishing you code! René

[sdickreuter]

Hi René,

thanks for you interest ! We use the project in its current state regularly for making nanostructures with small gaps. So I guess it is fit for production, but the question is if it is suitable for your project, as it has some limitations. It is made for use with a XENOS pattern generator, and can only be used for the proximity correction of small patterns made of point exposures (we use <5000 exposure points, the less the faster). Depending on the software you use for EBL it should be possible to adapt the output to a file-format that works for you. Some other point for concern is the point spread function of your EBL system, it might be necessary to measure it and use it for correction with EvoDose. Also I guess I need to do some cleanups and commenting to make the code nice :D

cheers Simon

[Aypac]

Hi Simon, thanks for the quick reply. We are using GDS2 files with our patterns. These are then loaded into a software that came with the eBeam (it's a 'Raith GmbH' eBeam, running the Raith NanoSuite). The (very manual) proximity correction (NanoPECS) running on our eBeam basically splits up the polygons defined in the GDS files (with varying size, according to need) and applies a dose factor on each sub-polygon. I would basically like to try to imitate this behaviour. [The further processing (splitting into write-fields, bitmap creation etc) happens pretty much 'under the hood' of the software.]

How is this package handling this? Is is 'just' making a bitmap of the defined polygons and then applying the correction on each pixel? What is on pixel in that case then? One Beam-Step-Size (BSS)? So does 5000 points mean something like a write-field of 70x70 Beam-Steps (so if using a BSS of 26nm, something like 1.2x1.2um)? What are the input- and output-formats? I tried reading the code and it appears, that the output is a point-cloud with the number of exposures (dwell-times) that shall be executed per point? And your desired structures are directly defined inside the code ("input-format")?

BTW: The different files are different structures you need, or is there a bigger difference between them? And fit_psf.py is used to fit the beam (alpha, beta, gamma, eta1, eta2), while proxtest.py plots different attributes of that beam?

Best, René

[sdickreuter]

Hi René,

good that you have Raith-System, because I just rechecked the files that I have not committed yet and remembered that I actually used EvoDose for Raith once. So you can have a look at the new file I commited, and I also attached an .asc file which you should be able to import into the Raith-Software so you can check it out. test_pillar_hexamer_60.asc.zip

Your guesses about the input and output format are correct, and because it is all in one file it is a bit messy, so I'll need to clean that up.

The working principle of EvoDose is quite different than a polygon-based software, that is because I found the proximity correction of polygons to be much more difficult than correcting single points, and because the XENOS software uses kind of a scripting language to define patterns, so single points are used often.

So here's how it works: Patterns are defined by exposure points (blue) and check points (red): The check points define the outline of the pattern. EvoDose now tries to optimize the doses of every exposure point so that the the dose that reaches the check points is as close to the wanted dose (here 600 uC/cm^2) as possible. After optimization the exposure points for example look like this (circle radii show the dose): With this one can also plot a dose distribution: The black line is where the dose is exactly at 600 uC/cm^2, and gives a clue on how the exposed pattern will look like if everything is perfect. Basically you can see how the psf smooths the dose distribution.

So EvoDose actually is suited best for small structures, where the dose inside the structure will be reached automatically by the exposure points on the outside. It is possible to setup structures with checkpoints on the inside, but it is harder to get good results. Also if you want to make thin elongated structures, the algorithm struggles to converge nicely, so one solution we used is to change the fitness function to include kind of the divergence of the dose of the exposure points which helps the algorithm to get a more symmetric result.

And last here is what the different files are:

• DoseCalc_evo and DoseCalc_Aya are basically the same, just with different parameters for the PSF
• DoseCalc_Dominik is also the same in principle, but there every but the most basic stuff is removed, so you want to check this one out, it even has some comments in it. You can also try to run it as it will generate some plots like the ones shown above. For using it with the raith, only the last part would have to be changed to generate a .asc file.
• DoseCalc_pixel and DoseCalc_pixe_threegaus are implementations which uses a pixel-based approach to proximity correction. I didn't try it in production though and it slower than the points-based approach.
• As you guessed correctly fit_psf is for getting the parameters of the psf from measurements
• proxtest is actually not important and I'll delete it

Regarding the 5000 points, this is the biggest structure we made with EvoDose, and it was made up of smaller structures. As you can see in the example above I used it usually for smaller stuff. Of course the calculation time scales with the number of exposure and check points, so for a structure with 5000 points you'll need a fast computer.

So I hope that helps. Also I might have some time this week to refactor the repo and make it to something less crude :D

cheers Simon

[sdickreuter]

Actually I had time today, so now it is much nicer. Lot of stuff is still left to do, but I guess it is ok for now. Also there are two simple examples which basically do the same thing but use different structures.

[Aypac]

Hi Simon, thank you a lot for all the explanation and code-cleanup! It is very clear to me now what this package does and how it roughly works :+1:

I'll have to review our use-case and see if we can apply this to our problem.

Best, René

Side-note for later reference: The ASC format seems to be pretty Raith-specific and not really open. But I found this 'Raith Software Reference Manual Version 5.0' in which in table 8 on page 34 there is a list of the syntax.

Click to show screenshots of the relevant passages (in case the PDF becomes unavailable).

 Part 1 of command syntax details  Part 2 of command syntax details 

[sdickreuter]

Hi René,

you are welcome, it was time to do some cleanup anyway ;) If you consider to use it for your stuff im pretty sure you could write an output function using the "point" element of the GDSII spefication you appended.

cheers Simon