Remote semiconductor microscopy

[0002] This application is based on U.S. Provisional Patent Application No. 60/082,846 entitled “Host Based Frame Monitor for Synchronized Video Acquisition and Compression” filed Apr. 23, 1998, and U.S. Provisional Patent Application No. 60/103,669 also entitled “Host Based Frame Monitor for Synchronized Video Acquisition and Compression” filed Oct. 9, 1998.

[0003] This invention relates generally to the field of semiconductor devices and, more particularly, to a method and system for inspecting semiconductor wafers via remote microscopy.

[0004] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawing hereto: Copyright 1999, Micron Technology, Inc., All Rights Reserved.

[0005] Microscopes are used to visually analyze the structural results of semiconductor processing. Fine features of semiconductor devices, such as transistor gates having sub-micron dimensions, are not readily visible to the human eye. Therefore, high performance microscopes, including scanning electron microscopes (SEMs) and scanning tunneling microscopes (STMs), are used to make these features visible. Semiconductor process engineers can, therefore, view these features to more efficiently diagnose problems that exist in semiconductor processes.

[0006] Conventionally, the images produced by microscopes are present only on monitors located with the microscopes. See Lampso, B. W. and Redell, D. D. (1980), Experience with Processes and Monitors on Mesa,Communications of the AACM, Vol. 23, No. 2:105-117. Often, the microscopes are located in the clean room complex of a wafer fabrication facility in which semiconductor processing is performed. Thus, wafers can be inspected in the midst of semiconductor processing without their removal from the clean room complex. As a result, the wafers are less likely to be contaminated by undesired particles that exist in far greater quantity outside the clean room complex. However, because the microscopes are located within the clean room complex, process engineers must necessarily don clean room uniforms, or bunny suits, and enter the clean room complex to view the inspected wafers. This technique is particularly inefficient when the process engineers, who are not normally stationed in the clean room complex, are required to enter the clean room complex to view microscopy results.

[0007] To enhance the efficiency of wafer inspection by process engineers, the present invention provides for a method and apparatus for remote semiconductor microscopy whereby video signals are broadcast from one or more microscopes to remote viewers. In one embodiment, a live video signal is broadcast from the microscope over a network to personal computers located in the offices of process engineers. The office-based process engineers are provided real-time, or substantially real-time, views of a wafer, including peripheral views of the wafer outside cell array boundaries. The process engineer, in his office, can direct a technician, operating the microscope in the clean room complex, to display a desired cell region-of-interest with the microscope.

[0008] Further, multiple process engineers can simultaneously view the video signal from the microscope(s). As a result, the process engineers can analyze, in real-time, or substantially in real-time, the information provided by the video signals. In this way, the process engineers can more efficiently collaborate to solve process problems, or even develop new process techniques.

[0009] Therefore, it is a benefit of the present invention that it diminishes the time in which semiconductor microscopy is performed. It is a further benefit of the present invention that it permits multiple process engineers to simultaneously review microscope data in real-time, or near real-time.

[0010] FIG. 1A is a block diagram illustrating one embodiment of a system for inspecting semiconductor wafers via remote microscopy;

[0011] FIG. 1B is a block diagram illustrating another embodiment of a system for inspecting semiconductor wafers via remote microscopy comprising two subnetworks coupled by a router;

[0012] FIG. 1C is a block diagram illustrating another embodiment of a system for inspecting semiconductor wafers via remote microscopy in which video can be communicated to remote clients by a wide area network such as the Internet.

[0013] FIG. 1D illustrates one embodiment of an analog video waveform in the RS-170 format;

[0014] FIG. 2 illustrates one embodiment of a video capture card having a frame rate suitable for capturing and digitizing video signals representing microscopic views of semiconductor wafers;

[0015] FIG. 3 further illustrates one embodiment of the software system of FIG. 5; and

[0016] FIG. 4 illustrates an exemplary timing diagram for the software system of FIGS. 3 and 5 when a single frame-grabbing resource is utilized;

[0017] FIG. 5 illustrates one embodiment of a software system to coordinate the capture of video signals from multiple sources;

[0018] FIG. 6A illustrates one embodiment of a Thread class and related subclasses ProducerFrameThread and ConsumerFrameThread;

[0019] FIG. 6B illustrates a state diagram for one embodiment of the Thread class;

[0020] FIG. 6C illustrates one embodiment of the ProducerFrameThread subclass;

[0021] FIG. 6D illustrates one embodiment of the ConsumeFrameThread subclass;

[0022] FIG. 6E illustrates one embodiment of the HostBasedFrameMonitor subclass;

[0023] FIG. 7 illustrates one implementation of the HostFrameBuffer;

[0024] FIG. 8A illustrates one implementation of the HostBasedFrameMonitor;

[0025] FIG. 8B illustrates an exemplary state diagram for the Condition class;

[0026] FIG. 8C illustrates an exemplary state diagram for the Monitor class;

[0027] FIG. 9A illustrates one embodiment of the Queue class;

[0028] FIG. 9B illustrates one embodiment of a Queue-Semaphore List class;

[0029] FIG. 10A illustrates one embodiment of a BinarySemaphore class; and

[0030] FIG. 10B illustrates an exemplary state diagram for the BinarySemaphore class.

[0031] The present invention provides a method and apparatus for remote microscopy useful to analyze semiconductor wafers. The term “wafer” used in the following description includes any structure having an exposed surface on which an integrated circuit (IC) is or may be formed. In another embodiment, the method and apparatus for remote microscopy may be used for other applications, including medical procedures. For example, during an operative procedure, and under the control of a pathologist, remote microscopy can be used to obtain diagnostic-quality images of microscopic tissue samples. The images are transmitted between geographically separated sites in real-time to permit remote consultation by other physicians. Further information about remote medical microscopy is provided in Dr. Gary J. Grimes, “Remote Microscopy for Hi Res Real-Time Interactive Pathology,” Advance Imaging,p. 12, July 1997, hereby incorporated by reference.

[0032] FIG. 1A illustrates one embodiment of a system 100 provided by the present invention. The system 100 includes one or more client computers 102a-102n,or generally 102, coupled to a server 104 by a local area network 106. In another embodiment, the clients 102 are generally located within the offices 110 of process engineers, which are outside the clean room complex 108. However, one or more clients 102 can be placed in the clean room complex 108. The server 104 may be located within or outside the clean room complex 108.

[0033] The server 104 is coupled to a video capture system 112 by a network 111, such as a corporate intranet. In one embodiment, illustrated in FIG. 1B, the network 111 comprises two subnetworks 161, 165 coupled by a router 113. The first subnetwork 161 couples the video capture system 112 to the router 113. The second subnetwork 165 couples the router to the server 104. The second subnetwork 165 also couples the server 104 to the clients 102. In one embodiment, the video capture system 112, server 104, and clients 102a-102noperate at 10 Megabits per second. In another embodiment, the router operates at 100 Megabits per second.

[0034] FIG. 1C illustrates another embodiment of the system 100 that utilizes a network 111 comprising the subnetworks 161, 165 coupled by a router 163, as described above. Additional clients 185a-185n,generally 185, can be coupled to the network 111 by a wide area network 187, such as the Internet, to permit unicasting of video over long distances. Further, each SEM 118, 120 is coupled to an analog multiplexer 116 through a video distribution amplifier 180, 182 having two video outputs. The output of each video distribution amplifier 180, 182, not coupled to the analog multiplexer 116, is coupled to an image still capture station 190, 192. Subsequently, the present invention will be discussed in view of the embodiment illustrated in FIG. 1A. However, such discussion may also be applicable to other embodiments.

[0035] The video capture system 112 may be located within or outside the clean room complex 108. The video capture system 112, for example a computer, includes a video capture card 114 coupled to a computer 115. In one embodiment, when the video capture card has limited, for example, one, analog video inputs, then an analog multiplexor 116 may be used to couple analog video signals from multiple microscopes 118, 120 to the video capture card 114. The analog multiplexor 116 can be manipulated directly, for example, by a microscope operator, or remotely through the system 100, for example, by a process engineer in an office 110, to select analog video signals 122, from one microscope to be broadcast to clients 102. Manipulation may be performed manually or electronically. In a further embodiment, the system 100 can control the analog multiplexor 116, for example, to automatically and sequentially select analog video signals 122 from the multiple microscopes 118, 120.

[0036] In another embodiment, when the video capture card 114 has a sufficient number of analog video inputs to uniquely couple each microscope to an analog video input, then an analog multiplexor 116 is not required in the system 100. In this embodiment, the multiplexor is part of the video capture card 114. Also, in this embodiment, the analog video inputs may be selected automatically by the system 100, or manually by the SEM operator or process engineer.

[0037] In yet another embodiment, the computer system operates in the following manner. The microscopes 118, 120 provide analog video signals 122. The analog video signals 122 may be in the RS-170 (without color burst) or RS-170A (with color burst) formats. One embodiment of an analog video waveform in the RS-170 format is illustrated in FIG. 1D. Alternate embodiments of such an analog video waveform 122 would include finite rise and fall times not illustrated in FIG. 1D. Analog video waveforms are further described in K. Jack, Video Demystified: A Handbook for the Digital Engineer,HighText, 1993, which is hereby incorporated by reference.

[0038] In one embodiment, the analog video 122 signal is coupled from the microscope to the video capture card 114 by a 75 ohm coaxial cable. If the video capture card 114 is located a substantial distance from the microscope, for example outside the clean room, a video distribution amplifier 180, 182 should be inserted between the microscope and the video capture card 114, as illustrated in FIG. 1C. In another embodiment, each frame of analog video 122 corresponds to one progressive scan of a scanning electron microscope (SEM) or scanning tunneling microscope (STM). Frames of analog video 122 from a microscope are digitized by the video capture card 114. The digitized frames of analog video 122 are provided by the video capture system 112 over the network 111 to the server 104. In one embodiment, the connection between the video capture system 112 and the server 104 uses a point-to-point transport control protocol-Internet protocol (TCP-IP). The digitized frames of analog video 122 are then stored in the server 104.

[0039] In one embodiment, still frames of video are captured, compressed and inserted into a database. Each image has a unique identifier which can be associated with a wafer or a lot of wafers. Therefore, a process engineer can select a specific frame of interest from stream content, and save a specific frame into a database.

[0040] In yet another embodiment, the digitized frames of analog video 122 are streamed over the network 106 from the server 104 to the clients 102. In a further embodiment, the streaming video format can be the Advanced Streaming Format (ASF) (Microsoft® Corporation, Redmond, Wash.), further described in a document published by Microsoft® Corporation and Real Networks™, Inc., entitled Advanced Streaming Format (ASF) Specification,Feb. 11, 1998, hereby incorporated by reference, and which may be found on the World Wide Web at http://www.microsoft.com/ asf/whitepr/asfwp.htm. Frames of digitized video data 122 are streamed in the ASF format by Netshow Server software operating on the server 104. The ASF video is played on the clients 102 by Netshow Player software. Netshow software is also a product of Microsoft® Corporation (Redmond, Wash.). However, the present invention can utilize other client-server streaming software, such as Real Video by Real Networks, Inc. (Seattle, Wash.).

[0041] In yet another embodiment, the digitized frames of analog video 122 can be stored on the server 104 as a file, such as in ASF, for viewing at a later time. Thus, microscopy video can be viewed remotely at a time substantially after the digitized frames of analog video data 122 have been captured by the video capture system 112.

[0042] The video capture system 112 will now be further discussed. A video capture card 114 having a relatively high frame rate is desirable. In one embodiment, the video capture card 114 is coupled to the memory and processor of the video capture system 112 by an Industry Standard Architecture (ISA) bus. An example of a video capture card, using an ISA bus, is a Winnov Videum VO (http://www.winnov.com). However, video capture cards that operate with ISA buses have limited bandwidth. For example, ISA buses operate with 16 bits at about 4 Megabytes-per-second. Thus, for example, the video capture card has a resolution of about 640×480×8; its corresponding maximum frame buffer-to-host memory transfer rate on the ISA bus is (4 Megabytes/Second)/307,200 Bytes=13 Frames/Second.

[0043] The relatively slow frame rate of the ISA compatible video capture card limits the frame rate of the video broadcast on the local area network 106 by the server 104. Therefore, a video capture card 114 having a higher frame rate is preferably used.

[0044] One embodiment of a video capture card 214 having a higher frame rate is illustrated in FIG. 2. The video capture card 214 is coupled to the memory 220 and processor 222 of the video capture system 112 by a Peripheral Component Interface (PCI), or IEEE-1394, bus 209. A PCI bus compatible video capture card 214 has greater bandwidth than an ISA bus compatible video capture card.

[0045] The video capture card 214 operating with a PCI bus 209 can be implemented with either Coreco Ultra II or F/64 video capture cards. The F/64 video capture card, which originally operated with an ISA bus, includes a high speed module on a daughter board to permit operation with the PCI bus 209. The PCI bus 209 has a maximum data rate of 132 Megabytes per second. However, generally, the PCI bus 209 operates at a data rate of about 80 Megabytes per second. For 640×480×8 resolution, the PCI bus compatible video capture card 214 has a maximum frame buffer-to-host memory transfer rate of (80 Megabytes/Second)/307,200 Bytes=260 Frames/Second, which is much greater than the 13 Frames/Second rate of the ISA bus compatible video capture card. Because of its higher frame rate, the video capture card 214 operating with a PCI bus 209 can facilitate higher frame rates on a local area network 106.

[0046] The Coreco F/64 will now be further described. The video capture card 214 includes an analog to digital (A/D) converter 201. The A/D converter 201 transforms one or more analog signals, such as analog video signals, into digital signals. Thus, in one embodiment, analog video signals from a microscope can be sampled and converted to digitized video signals 122 by the A/D converter. The sampling rate and number of bits of the A/D converter 201 will vary depending upon the type of A/D converter 201 used. The A/D converter 201 is coupled to a frame buffer 203 which captures and stores digitized frames of analog video 122. However, in an alternative embodiment, digitized frames of analog video 122 can be provided from a microscope directly to the frame buffer 203. The frame buffer 203 of the Coreco F/64, for example, can store up to 32 Megabytes of data.

[0047] The Coreco F/64 includes one or more digital signal processor(s) 205, such as graphics signal and histogram processors, coupled to the frame buffer 203. The digital signal processor(s) 205 may be used to manipulate, for example, capture, filter and/or analyze, the digitized frames of analog video 122. A captured digitized frame of analog video 122 is stored in the frame buffer 203. The digitized frame can be provided efficiently from the video capture card 214 to a processor 222, such as a Pentium II processor (Intel Corporation, Santa Clara, Calif.), through the PCI bus 209 by direct memory accessing (DMA). As a result, the processor is not required to perform extra processing, such as generating addresses. Alternatively, the digitized frame can be provided to the memory 220 through the PCI bus 209.

[0048] The Coreco F/64 can perform image processing, and the inventor has used it to explore digitized video data 122 of semiconductor microscopy. Specifically, the Coreco F/64 has been used to detect motion by evaluating changes in subsequent frames.

[0049] Generally, a video signal contains inherent redundancies both spatially and in time. Spatial redundancies, or statistical dependencies among neighboring pixels, are present because naturally viewed images are generally smooth. In other words, video images comprise primarily low frequency content, in addition to structured texture regions and connected edge boundaries. Temporal redundancies, or time-related statistical dependencies, are a function of how fast or slow object scenes move, as is discussed in M. J. T. Smith and A. Docef, A Study Guide for Digital Image Processing,Riverdale, Ga., Scientific Publisher, 1997, hereby incorporated by reference. Digitized frames representing a semiconductor wafer generally illustrate no motion, except when a stage of the microscope is panned or optics of the microscope are adjusted. Thus, successive digitized frames of a semiconductor wafer are generally very similar to one another.

[0050] The static nature of digitized frames of semiconductor wafers can be verified by using the real-time histogram processor (Texas Instruments, Dallas, Tex.) resident on the Coreco F/64. See, The Oculus-F/64 Frame Grabber User's Manual,Edition 1.0, Revision 2, Coreco, Inc., p. 3-7, June 1994; http://www.coreco.com. The real-time histogram processor can analyze multiple sets of two successive (i.e., first and second) digitized frames of a semiconductor wafer. As a result, a relatively slow video frame rate of 5 frames-per-second was found to be adequate for remote microscopy of semiconductor wafers. Also, generally, the difference between means of the video information in the sets of first and second frame, approached zero. For this reason, the video data of semiconductor microscopy was found to be a suitable candidate for compression, or encoding.

[0051] Therefore, in one embodiment, the video capture system 112 includes a video encoder, such as found in the Duck True Motion Real-Time encoder-decoder (CODEC) (Duck Corporation, New York, N.Y.), which encodes, or compresses, the captured frames of digitized video, and converts them into the ASF. The HBFM can be implemented using the Component Object Model (COM) (Microsoft® Corporation, Redmond, Wash.), further described in a document published by Microsoft® Corporation entitled The Component Object Model Specification,version 0.9, Oct. 24, 1995. The Duck True Motion Real-Time CODEC is implemented in software, and is an In-Process Active X component that is loaded into an existing apartment when the COM client, Host Based Frame Monitor, calls CoCreateInstance.

[0052] Encoding in the present invention can be implemented in the following ways. In one embodiment, the Duck True Motion Real-Time CODEC can reside in the memory 220, volatile or non-volatile, fixed or removable, within the video capture system 112. The CODEC would then be executed by the processor 222 in the video capture system. In another embodiment, the CODEC can reside in memory on the video capture board 214, and be executed by a processor 205 on the video capture board.

[0053] The Duck True Motion Real-Time CODEC uses a wavelet compression algorithm. Currently, the Duck True Motion Real-Time CODEC can compress frames with a resolution of up to 320×240×24, and at a frame rate of 30 frames-per-second. Because the output resolution of a SEM or STM is typically only an 8 bit grey scale, the Duck True Motion Real-Time CODEC is capable of being modified to handle higher frame rates provided by a PCI bus compatible video capture board, such as the Coreco F/64.

[0054] Using compression the efficiency of the video capture system 112 can be enhanced. In one embodiment, the statistical data output of the video capture card's histogram processor, described above, can be used to sense whether a scene change occurs from a first frame to a successive second frame, as described above. If the statistical data, such as the differential mean, is less than a threshold level, the video capture system 112 will retransmit the previously broadcast encoded first frame, which can be stored in memory 220, and not expend resources (e.g. processor time) to encode and transmit the second frame.

[0055] The compressed digitized video data is provided to the server 104 over the network 111. In one embodiment, the Netshow server streams ASF video files to the clients 102 over the network 106. The video compression, described above, minimizes the network 106 bandwidth required for broadcasting, either uni- or multicasting, the remote microscopy video to clients 102. In another embodiment, the Netshow player, resident on the clients 102, also includes the Duck True Motion Real-Time CODEC, to permit decompression of the video before it is displayed on the client 102.

[0056] However, the capture or grabbing of video data, for example by the video capture card 114, and the transmission of digitized video data from a high-speed bus, such as a PCI bus, to the memory 220 or the processor 222 must be coordinated with real-time video compression. Also, as illustrated in FIG. 1, multiple video sources (e.g. SEMs) may be coupled to the video capture system 112. Therefore, the system 100 also needs a technique to permit and coordinate the capture of video signals from multiple sources.

[0057] Therefore, in another embodiment, the present invention provides a Host-Based Frame Monitor (HBFM). In one embodiment, the HBFM is a software system stored on a computer-readable medium and performed by the processor 222 of the video capture system 112. The HBFM coordinates frame capture, video data transfer along the high speed bus, and real-time encoding of video signals from multiple sources. The HBFM can also be used to integrate otherwise incompatible imaging components, such as a video capture card 114 and CODEC software. The HBFM achieves this integration by segregating and synchronizing the processing of each digitized frame of the analog video 122. For example, the HBFM ensures that write operations (such as analog-to-digital acquisition) and read operations (such as compression) are performed mutually exclusively. Also, the HBFM permits read operations to be executed in parallel to the write operations.

[0058] In one embodiment, the HBFM is implemented in software, rather than hardware, so that any number of threads may be created dynamically at run-time to service many application-specific digital image processing needs. For example, for a single frame grabber resource, which may be a video capture card 114, one thread can grab a frame of video, another thread can compress another frame of video data, while yet another thread performs edge detection analysis on another frame of video data that is being compressed. Like the CODEC, the HBFM can reside and be executed in either the video capture card 114, or the video capture system 112. In another embodiment, the HBFM can reside in memory, volatile or non-volatile, fixed or removable.

[0059] In a further embodiment, the HBFM is implemented with object-oriented software, as described in Rumbaugh et al., Object-Oriented Modeling and Design,Prentice Hall, 1991, hereby incorporated by reference. The Appendix illustrates an exemplary embodiment of an Host Based Frame Monitor 302 that ensures that frames of video data are grabbed and compressed, or otherwise processed, in an orderly and synchronized manner. The embodiment illustrates an object-oriented implementation including classes used within the HBFM software system and the corresponding methods that collectively provide an application programming interface for retrieving and processing digitized video. In one embodiment, a producer thread object can be instantiated to grab video frame data from a resource, such as a SEM, and store the video frame data in a frame buffer object. A consumer thread object can also be instantiated to perform real-time encoding of other video frame data in another frame buffer object.

[0060] FIG. 5 illustrates one embodiment of an object-oriented software system 300 including HBFM 302. HBFM 302 can instantiate one or more producer thread objects 304 and one or more consumer thread objects 306. Each producer thread object 304 includes a ProduceFrame method to retrieve video data from frame grabber resource 310, such as video capture card 114, and store the video data in HostFrameBuffer 312. Similarly, each consumer thread object 306 includes a consumer frame method to retrieve the digitized video signal from the software frame buffer and to process the digitized video signal for communication to the remote clients 102. In this manner, the ProducerFrameThread class and the ConsumerFrameThread class present a set of application programming interfaces to HBFM 302 for retrieving, processing and communicating the digitized video signal generated by the video capture system. In another embodiment the methods are private to producer thread object 304 and consumer thread object 306 and are not available to HBFM 302.

[0061] If producer thread object 304 cannot immediately access corresponding HostFrameBuffer 312 then an identifier for producer thread object 304, such as a pointer, is placed in Queue object 314. Queue object 314 is instantiated at this time, if it does not already exist. Upon completing the grabbing of the frame, the ProduceFrame method invokes the StopGrabbing method of HBFM 302 to indicate that it has finished populating HostFrameBuffer 312 so that any ConsumerFrameThread 306 can begin operating upon the frame.

[0062] In one embodiment, the producer thread object 304 and consumer thread object 306 are executed inside a single process. Note, the HBFM 302 does not define how an analog image is digitized or how a digital image is compressed, but rather HBFM 302 ensures that frames of video data are grabbed and compressed, or otherwise manipulated, in an orderly and synchronized manner.

[0063] FIG. 3 further illustrates the object-oriented software system 300 of FIG. 5 including HBFM 302. HostFrameBuffer1, HostFrameBuffer2, and HostFrameBuffer3 are instances of HostFrameBuffer 312 of FIG. 5. ProducerThread1 (PT1), ProducerThread2 (PT2), and ProducerThread3 (PT3) are instances of ProducerFrameThread 302. Each produceFrame operation, such as produceFrame1, produceFrame2, and produceFrame3, retrieves a frame of digitized video from a corresponding HostFrameBuffer object such as HostFrameBuffer1, HostFrameBuffer2, and HostFrameBuffer3. Similarly, ConsumerThread1 (CT1), ConsumerThread2 (CT2), and ConsumerThread3 (CT3) are instances of ConsumerFrameThread 306 of FIG. 5. Each ConsumeFrame operation processes the frame of digitized video in a corresponding HostFrameBuffer object. For example, the consumeFrame operation may compress the frame of digitized video.

[0064] In one embodiment, each HBFM input signal source, such as a SEM signal, coupled to a single frame grabber resource 310, may be logically and uniquely associated with a distinct pair of producer and consumer threads as well as a corresponding HostFrameBuffer object 312. For example, referring to FIG. 3, if a frame grabber resource 310 is coupled to the outputs from three SEMs, then the most recent frame of digitized video from SEM 1 may be grabbed by the ProducerThread1 object, stored in HostFrameBuffer1 object, and compressed by the ConsumerThread1 object. The most recent frame of digitized video from SEM 2 may be grabbed by the ProducerThread2 object, stored in HostFrameBuffer2 object, and compressed by the ConsumerThread2 object. The most recent frame of digitized video from SEM 3 may be grabbed by the ProducerThread3 object, stored in HostFrameBuffer3 object, and compressed by the ConsumerThread3 object. The frames of digitized video are grabbed, stored and compressed in the manner described below.

[0065] However, for each HostFrameBuffer object HBFM 302 utilizes a single-producer/multiple-consumer locking protocol such that HBFM 302 is able to support multiple consumers for each producer. This protocol comprises two mutually exclusive states: the producer (write) state and consumer (read) state. In the write state, each HostFrameBuffer object receives a frame of digitized video from only one corresponding producer thread object at any time. In one embodiment, only one HostFrameBuffer object receives a frame of digitized video from a producer thread object at any given time. However, each HostFrameBuffer object may provide a stored frame of digitized video to one or more consumer thread objects at any given time when the HostFrameBuffer object is not receiving digitized video data from a producer thread object. This protocol has two purposes: first, multiple consumer process objects may simultaneously access a frame of digitized video in a single host frame buffer, and second, access to each frame grabber resource or video source is serialized.

[0066] In one embodiment, a single frame grabber resource may be connected to three video sources, such as cameras or SEMs. Each video source is associated with a distinct HostFrameBuffer object, and a corresponding section of the memory 220. In one embodiment, two separate processes are executed in host memory, for example, in the memory 220 of the video capture system 112. A first process may be an application or producer thread object that captures still images. A second process may be an application or a consumer thread object that performs real-time encoding.

[0067] In another embodiment, a single-process, including single producer and multiple consumer thread objects, is performed in memory 220 of the video capture system 112. The multiple consumer thread objects are permitted parallel, shared access to one HostFrameBuffer object. However, when a produceFrame method is performed by the producer thread object, only the producer thread object can update the HostFrameBuffer object with another video data frame; no consumer thread objects, or other producer thread objects, are permitted to access the HostFrameBuffer.

[0068] In one embodiment, synchronization is achieved in the following manner. A produceFrame method invokes a startGrabbing method and stopGrabbing method, respectively, before and after every frame of digitized video is grabbed. Before grabbing a new frame, a produceFrame method invokes a startGrabbing method, to make sure it can begin grabbing the new frame. If a producer thread object is not permitted to begin grabbing, and accessing its corresponding HostFrameBuffer, then the producer thread object is placed in the GrabWaitQueue object. The GrabWaitQueue object is instantiated at this time, if it does not already exist.

[0069] Upon completing the grabbing of the frame, the ProduceFrame method invokes the StopGrabbing method to indicate that it has finished populating the HostFrameBuffer object so that any consumer thread object(s) in the CompressWaitQueue can begin operating upon the frame.

[0070] A ConsumeFrame method invokes the StartCompressing method and StopCompressing method, respectively, before and after compressing a frame of digitized video, in a HostFrameBuffer object. Before compressing a frame, each consumer thread object invokes the StartCompressing method, to ensure that a producer thread object is not currently writing to the HostFrameBuffer object. If a producer thread object is currently writing to the HostFrameBuffer object, the consumer thread object is not permitted access to the HostFrameBuffer, and is placed in the CompressWaitQueue object. If not already existing, the CompressWaitQueue object is instantiated at this time.

[0071] After compressing the frame of digitized video in a HostFrameBuffer object, the ConsumeFrame method invokes the StopCompressing method to signal that it has finished compression so that a producer thread object seeking to use the HostFrameBuffer can be activated.

[0072] FIG. 4 illustrates an exemplary timing diagram for software system 300 including HBFM 302 when a single frame-grabbing resource is utilized. Initially, at time zero, PT1 invokes the Framegrabbers GrabFrame operation to begin to populate the Hostframe buffer object. At 1 millisecond in time, CT1 is placed on the CompressWaitQueue object because PT1 is not finished grabbing the frame.

[0073] Also at 1 millisecond, PT2 is placed in the GrabWaitQueue object because PT1 is not finished grabbing the frame. Only one producer thread object can access the frame grabber resource at a time. At 2 milliseconds, CT2 is placed in the CompressWaitQueue object because PT2 has not yet populated the HostFrameBuffer2 object. At 3 milliseconds, PT3 is placed in the GrabWaitQueue object because PT1 is still not finished grabbing the frame. Finally, at 4 milliseconds, PT1 finishes its frame grab and CT1 is permitted to access the frame stored in HostFrameBuffer1 object so that it can invoke the CODEC's CompressFrame operation. Thus, at 4 milliseconds, PT2 is permitted to proceed to write a frame to HostFrameBuffer2 object. Also, at 4 milliseconds, CT3 is placed in the CompressWaitQueue object because PT3 has not begun grabbing a frame.

[0074] For all producer threads PT1-PT3, the task of grabbing a frame is delegated to the FrameGrabber object; specifically its GrabFrame operation. For all consumer threads CT1-CT3, the task of compression (also called encoding) is delegated to the CODEC; specifically its CompressFrame operation. At 8 milliseconds, while CT1 delegates compression of the frame stored in HostFrameBuffer1 object to the CODEC object, PT2 finishes writing a frame. Thus, after 8 milliseconds, PT3 is removed from the GrabWaitQueue object, and proceeds to write a frame to HostFrameBuffer3 object. Further, CT2 is removed from the CompressWaitQueue object, and begins compressing the frame in HostFrameBuffer1 object.

[0075] At 10 milliseconds, CT1 finishes compressing the frame stored in HostFrameBuffer2 object. At 12 milliseconds, PT3 finishes writing the frame to HostFrameBuffer3 object. Thus, at this time, CT3 is removed from the CompressWaitQueue object, and begins compressing the frame stored in HostFrameBuffer3 object. Also, at 12 milliseconds, PT3 wants to produce a new frame, but cannot because CT3 is accessing the frame stored in HostFrameBuffer3 object. Therefore, PT3 is placed in the GrabWaitQueue object.

[0076] At 14 milliseconds, CT2 is placed in the Compress Wait Queue object because PT2 has not begun grabbing. At 15 milliseconds, PT2 also wants to produce a new frame, but cannot because PT3 is in the Grab Wait Queue object. Therefore, PT2 is also placed in the Grab Wait Queue object after PT3. At 16 milliseconds, PT1 also wants to produce a new frame, but cannot because PT3 and PT2 are in the Grab Wait Queue. Therefore, PT1 is also placed in the Grab Wait Queue object after PT3 and PT2.

[0077] Once CT3 finishes compressing the frame stored in HostFrameBuffer3 object at 18 milliseconds, PT3 begins to write another frame to HostFrameBuffer3 object. Also at 18 milliseconds CT3 again wants to compress another frame stored in HostFrameBuffer3 object. Because PT3 has not completed writing another frame, CT3 is placed in the Compress Wait Queue object.

[0078] At 21 milliseconds, CT1 wants to compress another frame in HostFrameBuffer1 object. However, because PT1 has neither begun nor completed its writing of another frame to HostFrameBuffer1 object, CT1 is placed in the Compress Wait Queue object.

[0079] PT3 completes writing a frame at 22 milliseconds. Then, at 22 milliseconds, CT3 begins compressing this frame stored in HostFrameBuffer3 object. Also at 22 milliseconds, PT2 is removed from the GrabWaitQueue object, and proceeds to write another frame to HostFrameBuffer2 object.

[0080] At 26 milliseconds, PT2 finishes writing the frame to HostFrameBuffer2 object, and CT2 is permitted to compress the frame stored in HostFrameBuffer2 object. Also at 26 milliseconds, PT1 is moved off the GrabWaitQueue object, and begins writing a frame to HostFrameBuffer1 object. At 28 milliseconds, CT3 completes compressing the frame stored in HostFrameBuffer3 object.

[0081] PT1 stops grabbing the corresponding frame at 30 milliseconds. Thus, at 30 milliseconds, CT1 is taken from the CompressWaitQueue object, and begins compressing the frame stored in HostFrameBuffer1 object. CT2 and CT1 complete their compressions respectively at 32 and 36 milliseconds.

[0082] Various embodiment are described for remote semiconductor microscopy whereby video signals are broadcast from one or more microscopes to remote viewers. Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement which is calculated to achieve the same purpose may be substituted for the specific embodiment shown. This application is intended to cover any adaptations or variations of the present invention. For example, those of ordinary skill within the art will appreciate that in one embodiment, a live video signal is broadcast from the microscope over a network to client computers located in the offices of process engineers. In another embodiment the process engineers can selectively view still images retrieved from a database. The client computers may receive the video signals via a local network or even a wide area network such as the Internet. In addition, the method and apparatus for remote microscopy may be used for other applications, including medical procedures.