JobFiles - Introduction & Overview


To write a pattern with the e-beam system, you will also have to create a set of “Job Files”, which are instructions which tell the e-beam system what patterns to write, where to place the patterns on the wafer, what beam and writing conditions to use, what doses to use, alignment to prior layers, calibrations, etc. The JEOL uses a “compiled” architecture in which you have to prepare all control files, patterns and job files, in advance, and “compile” them into a runnable job. (This is in contrast to an interactive, or “interpreted” architecture where the system responds directly and immediately to commands you enter.)

From the user perspective, a compiled architecture usually means:
  • More work up front, because you have to get all the files created in advance before any work at all can begin
  • A steeper learning curve, because you have to learn a significant amount about the jobfile setup in order to produce even the most simple exposure
  • Simpler operation at runtime, with more likelihood of success. All the work is done in advance. Run Time is an anti-climax. You click “go” and it “goes.”

In this case, the Job Files refer to two or more distinct files, of two varieties. Each file is an ASCII text file, and can be edited with most any file editor. (You have to be a bit careful about “line ending characters” if you create you files on platforms other than Unix computers, in particular when you transfer the files to the e-beam computer.) The structure, syntax, and punctuation of these files is rather arcane, not very intuitive, and pretty difficult to learn. It’s always easiest to start with a set of working files, hopefully close to the job you want, and then edit the parts that need to be changed.

This figure shows that for each exposure job, you’ll need to create:

  • One “Schedule File”, with filetype: .sdf.
  • One or more “Job Deck Files”, with filetype: .jdf

Again, these are ASCII text files. These files are then run through a compiler program (abbreviated “SCHD”) on the e-beam computer, which will output a binary (non-human-readable) control file called a Magazine, or .mgn file. It is this file that the e-beam system will use to actually write the job on the wafer.



There’s a good amount of flexibility in these files -- for most jobs, there are multiple ways the same results can be achieved, but some are much easier than others, and some allow far more flexibility for future changes, better compatibility for multi-layer projects, etc. So it pays to think a bit about how to optimally structure your files. Feel free to talk your plans over with the e-beam staff before you invest too much time; you might save yourself a lot of work.

As an example, some commands can appear in different places within the file set - you can have the same commands appear in the .SDF file, in the common block of the .JDF file, or in a layer block of the same .JDF file. This is perfectly fine, as long as you understand the scope and precedence -- that is, which command actually has effect on a specific part of a given write. In general, settings made “later” in the file set usually take precedence over earlier settings. For example, if you define a pattern with the P() command in the common block of a JDF file, and then later re-define the same pseudo-pattern index with another P() command in the layer block of the same JDF file, the definition in the LAYER block will take precedence. However, a P() command in the SDF file will override any P() command in a JDF file! Confusingly enough, however, the offsets from the JDF file will still apply! It’s complicated, but it bears some attention up front if you hope to get your desired results.