Raith write report: broken patterns and more...
altug at stanford.edu
Sat Jul 17 12:21:27 PDT 2004
Hi Gigi and all,
I had similar "broken pattern" problem last September when pattern generator
was broken and some pictures are on Raith Swiki. For a long while it was
happening only on my patterns while other people were getting good results.
It might be related to the complexity of the patterns. The problems that you
are reporting might be caused by the same error.
----- Original Message -----
From: "Luigi Scaccabarozzi" <scaccag at stanford.edu>
To: "Joseph Klingfus" <jk at raithusa.com>
Cc: <raith at snf.stanford.edu>; "'Kahl, Michael'" <Kahl at Raith.de>;
<jwc at snf.stanford.edu>; "Nathaniel Burt" <nburt at ksu.edu>
Sent: Saturday, July 17, 2004 12:11 PM
Subject: Raith write report: broken patterns and more...
Hi Joe and everybody,
I report here the problems I had in the past 3 writes, during the last 3
The pattern, attached as gds file consists of plain waveguides (basically
boxes) and tapered waveguides (boxes + triangles, one next to the other).
I wrote the cell MainTAPER1, which consist of 6 sets of cell1, rotated by
mean of the cell TotalMask, in order to write the waveguide along the X
direction (to avoid drifting). Actually I hope I attached the updated mask
(I don't have a hardlock key with me right now, to check, but eventually
the only difference should in the number of subsets "cell1" included in
the main pattern.
This is a slightly different pattern than the one I used to write in
past, but 1) I got the same problems also with the old pattern, which I
included for test and 2) the broken pattern are not supposed to be there
In my FIRST write I tried using 10 keV, 20 um aperture (usually I use 10
um). This gave the problem of some charging and I attributed to the
aperture the errors in written pattern.
This added to the fact that I had to use 570X MAG, instead of 600X, and
the values of zoom x/y were 1.41/1.48. However in the written pattern
squares came out "square", so eventually this should not be a problem, a
part for the weird values of zoom.
The other parameters are:
current 0.080 nA (20 um) / 0.020 nA (10 um)
area step size: 8 nm
dose 140 uC/cm^2
beam speed 7.1 mm/s (20 um) / 1.7 mm/s (10 um)
***LINE MODE OFF*** this to avoid the bug in the software of notches at
the boundary of patterns next to each other... as found out by Micheal and
me last year.
The SECOND write was a test write and I tried both 20 um aperture and 10
um aperture. 20um still had signifiacnt errors, 10um looked much better,
no stitch error, but some broken pattern. The result was not great but
good enough, so I decided to try a long write with 10 um.
The THIRD write, overnight, with 10 um aperture included 4 chip
(MainTAPER1), each one with reduced working area, so that only 4 subset,
instead of 6 were included.
In this write I reproduced exactly the same conditions I used in past and
that used to work perfectly. In particular the WF alignment was extremely
good, as good as in past.
I attach some pictures of the results of this last write, which are
also representative of the previous ones.
Interesting is that the first subset of the first chip was written almost
perfectly (just a couple of error). All the other pattern (which is 15 out
16) have a stitch error (write fields shifted vertically by ~0.5 um),
present in all the writefields, and a few broken patterns.
You can judge by yourself, but according to my modest opinion, the problem
with MAG that needs to be decreased and these broken patterns suggest that
we have a real problem, either with the pattern generator or something
else. I add that we started having this problem on monday, after the
problem of the loadlock venting over the wekend.
Finally, I heard another user (ryan) saying that his write went ok,
however I have no idea if he need good stitching or he has complex
patterns. So I wonder if these errors are pattern dependent or affect only
complex patterns, or....
If someone tries to write anything, please report the results!
Joe, what do you think? I hope that we can have this problem
cleared/solved by the time (or at least while) you'll be here on
wednesday. I also have found other minor problems/errors with I'd like to
discuss with you wed or thur.
On Thu, 15 Jul 2004, Joseph Klingfus wrote:
> Gigi, all,
> It is a puzzle why 600 worked before, but now you need 580. No
> as of yet, but I would accept 580 and go with it. It should be standard
> operating procedure to do an AlignWF before an exposure so you will always
> be sure the field size is correctly calibrated.
> I will be in the lab on Wednesday and Thursday of next week installing a
> Raith computer. Perhaps on Thursday afternoon we could discuss the simple
> test I outlined and I can describe what I would be looking for in steps 5,
> 6, and 9.
> Likewise, if any users are having any difficulties on the system, please
> prepare something if coming to see me. It does little good to "wave
> in the air trying to describe what the GDSII design looks like compared to
> the end result. Please have a few images and patterns ready.
> I know several users have been suffering from beam current leakage through
> the beam blanker. This is being handled through our service department.
> Perhaps they will have some ideas for me to try when I am on-site. Lets
> HI Joe,
> we did what you suggested and everything seems fine in terms of slowscan
> images, although I'm not sure what I should look for exactly. Anyway, we
> tried decereasing the MAG to 580 (instead of 600) and the zoom x and zoom
> go back within the limits and I can complete the align writefield. I
> tried a test pattern yet (other users where using the system today and
> don't really need and precide align writefield), I'll try tomorrow.
> The only thing I'm worried about is the realtive value of the zoom
> at 580X they are zoom X:1.37, Y: 1.47, which means 0.1 difference, where
> used to be 0.01. Should this still be ok? Does this ring any bell?
> To RAITH USERS:
> in the following days please report your results, especially stitch error
> and deformations, so that we can check if the anomalous zoom values are
> affecting the writes.
> On Wed, 14 Jul 2004, Joseph Klingfus wrote:
> > Hi there Gigi,
> > My apologies, of course I shouldn't assume that the pattern generator
> > (PG) couldn't be broken. It might be. Please do the following as a
> > test:
> > 1) Turn the PG off, wait a short time and power back on.
> > 2) Restart both PC's.
> > 2) Check Polaroid 545 setting again on the LEO.
> > 3) Load the Chessy calibration target (as square as possible on the
> > stage) and go to your normal working distance (stage Z) and set a 100
> > µm WF.
> > 4) Because the Chessy is sitting squarely on the stage, the SEM scan
> > rotation should be 0 and AlignWF rotation values should be nearly 0.
> > 5) Collect a SlowScan image of the Chessy with the PG and see if
> > looks OK.
> > 6) Have the AlignWF window visible on the desktop and try an align WF
> > procedure. (Remember, be very aware of your Scansize and Placement
> > There are 1 µm squares composing larger 10 µm squares. Don't confuse
> > box intersections are the correct targets.)
> > 7) Write down the calculated zoom correction factors that the system
> > to apply.
> > 8) Hopefully accept the corrections without errors and collect another
> > SlowScan image.
> > 9) If you selected the right box intersections the Chessy should be
> > perfectly aligned and sized in the image.
> > Please let me know how this turns out.
> > To answer your question of WD...
> > The Zoom U/V parameters do not depend so much on WD because the SEM
> > takes care of this internally. Imagine setting a MAG of 600 X (~ 100
> > µm WF) both at high and low Z height. The MAG determines the scale of
> > things we see on the display screen. It still takes a voltage sweep
> > of +/- 5 Volts on the external column inputs to raster the electron
> > beam from side to side across the image. (just using 5 V as an
> > example, all SEMs are different) This is why we (Raith litho) don't see
> any great effect on Zoom U/V parameters as WD
> > changes. Although, for good stitching results do an AlignWF at the Z
> > height you are writing at.
More information about the raith