Impact of parallelism on data volumes for a multibeam mask writer

Single beam variable-shaped beam (VSB) systems have been extensively used in the mask fabrication industry for years, but they are not equipped to handle future throughput and resolution requirements. The development of multibeam mask writers is in progress to address the needs of sub-10 nm technology nodes.^1–7 The multibeam mask writers proposed by IMS Nanofabrication^1,3 and NuFlare⁷ transfer patterns using grayscale dose assignments on a pixel grid. These grayscale representations are predicted to create data volumes on the order of petabytes of data and need to be transferred at very high data rates.^5,6 Layout image compression and massively parallel architectures have been proposed to deal with the data transfer problem in electron beam direct write lithography systems,^8–27 and the reflective electron beam lithography (REBL) system²⁸ included a lossless layout image compression algorithm as part of its digital pattern generator.¹³ The data compression efforts motivated by the REBL and MAPPER (Ref. 29) systems focused on layout image compression algorithms. The data compression problem considered in this paper is different because of the way the proximity-corrected layout data must be processed and distributed among the beams prior to transmission.

This work is inspired by the IMS Nanofabrication multibeam mask writer series eMET.^1,3 Since the writing strategy for this architecture is proprietary, we consider an idealization based on some known parameters. The eMET series proof-of-concept tools use an aperture plate system consisting of a square array of 512 × 512 programmable beams all of which are either 20 or 10 nm to write on a 5 nm pixel grid. The arrays we study have dimensions of $2N×(2N−1)$ beams, where N is an odd integer. To achieve some desirable properties in our family of beam arrays, we find that the distance between successive shots written by a single beam should grow as the array size increases. Therefore, the data handled by a single beam does not have the structure of a layout image. We study how compressed data volumes change as the array size increases. Like the eMET series, we incorporate beam shot overlaps which result in multipass writing to achieve a desired pattern. We use two dimensional filtering of gray images and a scanning strategy to solve the problem of assigning data to individual beams so that they jointly generate a pattern by means of multipass writing through the appropriate beam shot overlaps. We propose an effective scanning strategy for our series of beam arrays and argue that using a large number of simple data compression decoders in parallel can be a practical approach to reducing data volumes while transferring data at high rates.

The remainder of paper is organized as follows. In Sec. II, we present the details of our proposed multibeam architecture. In Sec. III, we describe the datapath problem and possible solutions as well as the data compression schemes used in this work. In Sec. IV, we discuss the experimental results for two sets of data, and we conclude the paper in Sec. V.

We begin by describing how we incorporate characteristics of the IMS eMET series into our model of multibeam systems. Like the IMS Nanofabrication system, we assume each beam can write a sequence of shots each having 16 possible dose levels in the set ${0, …, 15}$⁠. The system as a unit can produce a larger range of gray levels by means of the multipass writing that occurs from the shot overlaps of different beams. When the beam array is set to 10 nm beams, a shot from a single beam overlaps with four other beam shots so that each 5 nm pixel is written by four beam shots. The sum of four integers each of which is an integer between 0 and 15 is an integer between 0 and 60, so each 5 nm pixel in this case could have 61 possible dose levels. Figure 1 shows an example of beam shots with values 15, 14, 13, and 12 combining to create a pixel with dose value 54. Similarly, when the beam array is set to 20 nm beams each 5 nm pixel is written by 16 beam shots and hence could have 241 possible dose levels. Figure 2 illustrates the overlap of multiple Gaussian beams shots in a region to create a curvilinear pattern.

Given the pattern to be printed and the overlap of beams shots, it is necessary to solve a dose assignment problem to provide individual beams with appropriate sequences of 4-bit shot dose data. The beam shot overlap problem has been studied in the context of VSB shot overlaps.³⁰ To model the dose assignment problem, assume an input “shot” image IN(x, y) with possible shot dosage values ${0, …, 15}$⁠. The pattern image OUT(x, y) can be obtained by using the two-dimensional spatial filters H₁₀ and H₂₀ shown below, respectively, for 10 nm beam shots and 20 nm beam shots

We consider the two-dimensional convolution of the shot image IN(x, y) with H(x, y). The shot dose assignment problem reduces to finding IN(x, y) given the pattern image OUT(x, y) and the filter H(x, y). Similar deconvolution problems generally do not have unique solutions.³⁰ The H₁₀ and H₂₀ filters resemble blurring filters from image processing, and there is a literature on deconvolution algorithms³¹ 

Most image deconvolution problems are primarily concerned with image visibility, but the constraint in this application is that each shot dose value is chosen in the set ${0, …, 15}$⁠. We handle the deconvolution problem by using a least squares deconvolution algorithm with box constraints. Let Y be OUT(x, y) converted to a column vector with pixel values becoming elements of the vector, X be IN(x, y) converted to a column vector and A be an appropriate transformation of the H(x, y) filter into a two-dimensional convolution matrix. Let $||Z||2$ denote the Euclidean norm of an n-dimensional vector Z; i.e., $||Z||2=|Z1|2+|Z2|2+⋯+|Zn|2$⁠, where Z_i denotes the ith component of the vector Z. We would ideally like to consider the optimization problem

The integer constraints make this a combinatorial optimization problem which is infeasible given our computational resources. Therefore, we instead approximate the solution by working with the following convex relaxation and setting each X_i we obtain to the closest integer in ${0, …, 15}$

The IMS eMET system uses a 512 × 512 array of square beams arranged as a matrix of 512 rows and 512 columns. The square beams are created by passing a broad beam through an aperture plate system which consists of an aperture plate and a deflection plate. The aperture plate has 262 144 square apertures and can be set so that all of them have dimensions 2 × 2 μm or all of them have dimensions 4 × 4 μm. The center to center distance between apertures in a row or a column is 32 μm. The entire beam array is demagnified by a factor of 200 by means of electron beam optics to form 262 144 square beams on the wafer which all have dimensions 10 × 10 or 20 × 20 nm. The demagnification reduces the center to center distance between the neighboring beams in a row or a column to 160 nm. Given that the pixel size is 5 nm, a shot from a 10 nm beam exposes an area of four pixels and a shot from a 20 nm beam exposes an area of 16 pixels. The center to center distance of 160 nm between neighboring beams is equivalent to a distance of 32 pixels. The deflection plate is positioned just below the aperture plate and uses the 4-bit shot dose data to deflect individual beams one of 16 possible time intervals for each shot by turning individual beams on or off. Figure 3 illustrates the aperture plate system and a 13 × 13 beam array on a wafer. An entire beam array occupies an area of 16 384 × 16 384 pixels or approximately 82 × 82 μm on the wafer and approximately 16.4 × 16.4 mm on the aperture plate.

To investigate the effect of parallelism on data volumes, we study arrays of varying dimensions. The beam arrays we consider have dimension $2N×(2N−1)$ beams; i.e., they form a matrix with $2N$ rows and $2N−1$ columns, where N is an odd integer. The center to center distance between neighboring beams in a row or a column is $20.5(N+1)$ pixels; observe that this increases as N grows. Furthermore, the case where N = 9 corresponds to an array with 512 × 511 beams and a center to center distance of 32 pixels; hence, this beam array is the closest one to the one used in the IMS eMET series.

The IMS eMET beam array system deflects the entire beam array as a unit. While the distance between neighboring beams is $20.5(N+1)$ pixels, the system as a unit must write every pixel. A raster scan might be a first guess for a scanning strategy, but this approach would either lead to pixels written by more than four beams in the 10 nm case or 16 beams in the 20 nm case or to large shifts of the beam array. Therefore, we instead propose a zigzag scanning strategy described in Table I and depicted (for the first three steps) in Fig. 4 in the case of an 8 × 7 beam array with 10 nm beams. This approach ensures that pixels are written four times for the case of a 10 nm beam and 16 times for the case of 20 nm beams. Most of the time the beam array will move a distance of $0.5d$ pixels in the X-direction and +1 or −1 pixel in the Y-direction. This can be implemented by simultaneously controlling the stage and beam array so that the stage moves in the X-direction and the beam array is deflected in the Y-direction. Observe that the distribution of sequences of 4-bit dose values to each beam will depend on the scanning strategy.

The largest beam array we study is a 512 × 511 beam array and it has 261 632 beams. Since each beam requires a sequence of 4-bit shot data, a total of 1 046 528 bits are used at each step of the beam array. If the beam array can be deflected at 1 MHz, i.e., if each step can be completed in 1 μs, then the beam array processes approximately 1 terabit of shot data per second. Uncompressed data transmission at this speed would not be an effective communication strategy. We would have to store petabytes of uncompressed shot data on a device and transfer it directly to the electron beam writers. As shown in Fig. 5, the communication capacity and storage device memory would constrain this approach. A second approach depicted in Fig. 6 is to compress the data by a single complex compression algorithm and decompress it on a field-programmable gate array or an application-specific integrated circuit close to the electron beam writers. This approach would decrease the amount of data held on storage devices and would reduce the communication capacity needed between those devices and the decoder. However, this approach would be hampered by decoding speeds as well as the communication capacity needed from the decoder to the electron beam writers. A third approach depicted in Fig. 7 is to have a large number of simple decoders in parallel close to the electron beam writers. Simple decoders can decompress data at faster data rates than a complex decoder. We believe the third approach is the most effective way to communicate data at speeds of terabits per second to the electron beam writers. In this paper, we consider the simplest conceptual model in which each beam writer has its own decoder.

In considering this data compression problem, we observe that the overwhelming majority of layout images that we have seen are sparse, i.e., the fraction of symbols with value zero is much larger than 0.5. We expect that the images printed by electron beams for complementary lithography³² would also be sparse. The beam shot image obtained after applying the deconvolution procedure to a sparse pattern is also sparse. Run length encoding is a practical approach to compressing the zeros in sparse data. Since there are relatively few nonzero symbols in the beam shot data we can either transmit them without compression or we can apply Huffman encoding³³ to them. We distribute the shot image data among the beams according to the scanning strategy for that beam array. We transmit each beam's shot data separately and hence have to compress 56 data streams for an 8 × 7 beam array, 992 data streams for a 32 × 31 beam array, 16 256 data streams for a 128 × 127 beam array and 261 632 data streams for a 512 × 511 beam array.

For any representation of the nonzero symbols, the compressed symbol stream can be expressed in the form $R1N1R2N2...RnNnRn+1$⁠, where R_i refers to the encoding of the $ith$ run of zeros and N_i denotes the representation of the $ith$ nonzero symbol.

The first step in any run length code for a sparse data sequence is to count the zeros between successive nonzero symbols. For example, the data stream 02400000050000300000 would have an intermediate representation as $01200 406 504 305$⁠, where $0x$ denotes a string of x zeros. There are many ways to encode the set of run lengths, and in terms of compression performance, it would be ideal to choose the code based on the distribution of run lengths for the given data sequence. However, because decoding speeds and hardware implementations are critical for this application, we focus on two families of codes that are used in video standards and a more recent code which can be viewed as a hybrid of those two types of run-length codes.

Golomb³⁴ published the first paper on run-length codes 50 years ago. Rice^35,36 considered a special case of the problem Golomb had discussed and described an encoding procedure which is commonly called the Golomb–Rice code. The Golomb–Rice code is used in audio coding standards such as MPEG-4 ALS and in image coding standards such as JPEG-LS. There are Golomb–Rice decoders which are components of video decoders and operate at 10 gigabits per second on a 500 MHz/16 nm process and at 7.6 gigabits per second on a 380 MHz/28 nm process.³⁷ The encoding for non-negative integer i in a Golomb–Rice code with parameter k uses $k+1+⌊i/2k⌋$ bits.³⁸ 

Gallager and Van Voorhis³⁹ generalized the results of Golomb and proposed a code which is optimal when the run lengths have a shifted geometric probability distribution. For an arbitrary data set, let p be the fraction of zeros and let l and k be the integers for which

The encoding for the non-negative integer i uses $k+⌊(i+2l−2k)/l⌋$ bits. For any Golomb–Rice code, there is a Gallager–Van Voorhis code which compresses data at least as well, so we use the latter code for our experiments.

The other family of run-length codes to find wide application was proposed first by Elias⁴⁰ under the name of “gamma” codes and independently by Teuhola⁴¹ with the name exponential-Golomb (or Exp-Golomb) codes. These codes are used in the H.264/MPEG-4 AVC and H.265 HEVC video standards. Like the Golomb–Rice codes they are defined in terms of a non-negative integer parameter k. We can construct the order-0 exponential-Golomb code as follows. To encode a run of length i begin by writing the binary representation $bi+1$ of i + 1. Suppose $bi+1$ has $li+1$ bits. Then, we encode the string $0i$ in our data by $0li+1−1bi+1$⁠. For example, the encoding process for the first few non-negative integers is described below

The order-k exponential-Golomb code can be obtained from the order-0 code as follows. To encode a run of length i begin by finding the order-0 exponential-Golomb representation $ci+2k−1$ of integer $i+2k−1$⁠. Then, the desired codeword can be obtained from $ci+2k−1$ by removing the leftmost k bits from $ci+2k−1$⁠.

The exponential-Golomb codes have similar decoding throughputs as the Golomb–Rice decoders within video decoders, and neither type of code forms the bottleneck in video decoding.⁴² It is possible to have faster hardware implementations of both types of run-length codes.⁴² In 2013, Mediatek⁴³ reported a lossless Lempel-Ziv^44,45-like decoder which operated at 2 gigabits per second and occupied an area of roughly 40 000 μm² including space for memory. The Golomb–Rice and exponential-Golomb codes do not require searching and storing parts of the decoded data, so these run-length codes will have smaller and faster hardware implementations than the Lempel-Ziv codes.

While the preceding run-length codes are the ones which are best known, it is possible to consider others. Therefore, we include results on a more recent code by Xue et al.⁴⁶ which is designed as a hybrid of the Golomb–Rice codes and the exponential-Golomb codes.

We have done our experiments on two sets of data. One image is an inverse lithography technology (ILT) mask motif pattern of contact holes with smallest element of 80 nm. We enlarged this pattern by repeating it to generate a layout image of dimension 30 017 × 33 300 pixels. We also provide results for a 25-layer image compression block based on the FREEPDK45 45 nm library with a smallest element of 60 nm. The GDS file for this data set the pixel size to 30 nm, and we demagnified this data to produce 5 nm pixels. Each layout image for this circuit has dimensions 30 403 × 30 324 pixels. Proximity correction algorithms have been shown to apply for patterns written with overlapping shots,⁴⁷ and we used the electron beam proximity effect correction algorithm of GenISys, Inc., BEAMER_v4.6.2_x64 (Ref. 48) to generate proximity corrected images with the appropriate number of shot dose levels. After obtaining the proximity-corrected images, we experimented with two approximate deconvolution techniques to create the shot dose images. The so-called “crude” deconvolution algorithm produced the dose shot image by taking the integer part of one quarter of each pixel value of the pattern for 10 nm beams and by taking the integer part of one sixteenth of each pixel value of the pattern in the case of 20 nm beams. The least squares deconvolution algorithm for an entire image is an optimization problem with approximately 10⁹ variables, and we do not have the computational resources to solve such complex problems. Therefore, we approach least squares deconvolution by dividing each image into 1040 smaller images and using a supercomputing facility to separately solve the smaller deconvolution problems. It would be interesting to find better deconvolution algorithms for this application. The shot dose image was converted into shot data sequences for each beam according to the size of the beam array and the scanning strategy for that beam array. To correctly write pixels at the edges of stripes, we have to augment each beam's shot data sequence with extra zero symbols, but this additional data amounts to a small fraction of the total uncoded data if the size of the pattern is sufficiently large compared with the size of the beam array.

We present the results for the ILT motif pattern in Tables II and III and in Fig. 8. Figure 8 plots the compressed data volumes for different combinations of compression schemes, deconvolution algorithms, and beam sizes. In Table II, we summarize information about the best code for each beam array for least squares deconvolution including data volumes. Table III shows the nonzero symbol data volumes for uncoded and Huffman coded data. In Fig. 9 and Tables II and IV–VIII, we present results for the 25 layers of the image compression block. Here, we separate the results for the sparse and dense layers. Figure 9 plots the compressed data volumes of the 23 sparse layers of the image compression block. Table VIII offers details about the compression results for the individual layers for one choice of parameters.

The compressed data volumes increase with the size of beam arrays. The volume of the compressed nonzero symbols remains the same for all beam array sizes, but the compressed volume of zero symbols increases with the beam array size. This is mainly due to the increased randomization of the data assigned to each beam because the distance between the shots written in successive steps by a single beam grows with the size of the beam array. In the case of the 512 × 511 beam array, the size of the image is small enough that edge effects require the addition of many zero symbols to the uncoded data. We see that the exponential-Golomb codes are the best codes in most cases. Furthermore, the order of the best exponential-Golomb code increases with the size of the beam array.

In the 23 sparse layers of the image compression block, most of the compressed data volume comes from a few layers which have a large number of nonzero symbols. Some of the layers are particularly sparse and run-length encoding can compress them easily. The two dense layers are compressed only by Huffman encoding. In these layers, nearly every pixel is assigned some nonzero dose level.

The deconvolution algorithms also have an effect on compressed data volumes. With least squares deconvolution, the nonzero beam shot values are distributed over the entire range ${1,...,15}$ and Huffman coding does not compress this data effectively. With crude deconvolution, the beam shot values are distributed over a smaller range and there are fewer zero shot values prior to compression. While the choice of deconvolution algorithm affects compression performance, we can conclude that data compression significantly reduces data volumes for sparse patterns.

We have presented a family of multibeam arrays and proposed scanning strategies for them. We have also shown that the dose assignment problem for beam shot overlaps can be modeled by the two-dimensional filtering of gray images. Data compression appears to be an important tool to address the “big data” problems of the mask industry. We focused on simple and widely implemented run-length encoding schemes and argued that they are effective and practical. We concentrated on an idealized case where each beam has its own decoder and we do not discuss synchronization and networking issues. These problems need to be addressed for the incorporation of data compression into multibeam mask architectures and we observe that video decoders also have synchronization requirements.

The authors thank the National Science Foundation for the support of Grant No. ECCS-1201994. This research was made possible by the support of GenISys, Inc., which was given through an Agreement of Cooperation between GenISys, Inc., and Texas A&M Engineering Experiment Station at College Station. The authors used a supercomputing facility at Texas A&M University to conduct part of the research. The authors are grateful to N. Hayashi of Dai Nippon Printing for contributing an ILT test layout image and to D. Lie and S. Mukhopadhyay for supplying the image compression block. Finally, the authors thank T. Groves, J. Yang, and S. Khatri for stimulating conversations. The image compression block data prior to deconvolution can be found at http://people.tamu.edu/narendra5/.