Software interfacing for 375

Get Started. It's Free
or sign up with your email address
Software interfacing for 375 by Mind Map: Software interfacing for 375

1. Problems

1.1. SensingLight type is used everywhere.

1.1.1. It describes the discrete filters in 350 and a lot of code depends on that discreteness.

1.1.2. Not clear where logical application acquirement's end and where machine acquirement's start.

1.2. The IMeasure interface depends on a CalibrationDataContainer.

1.2.1. MeasurerAdministrator depends on a key -> value relation using the CalibrationId as key and CalibrationDataContainer as value. For continuous wavelength in combination with interpolated calibration data this will not work.

1.2.2. CalibrationDataContainer depends havely on EC structures that will need to change for 375.

1.2.3. CalibrationDataContainer contains all data that is possibly needed for every application.

1.3. Lots of (Proxy) interfaces will not work anymore on 375.

1.3.1. E.g. GetAvailableSensingLights

1.3.2. E.g. GetActualWavelength

1.3.3. E.g. TakeImage(discrete-sensinglight)

1.4. Sensing equipment-constants are used directly in measuring and machine control code.

1.4.1. Retrieve data like the actual wavelength of a discrete filter or the filters that are installed in the machine.

1.5. Maintainability issues

1.5.1. In a lot of cases machine dependent information (SensingLight, Aperture, Spotize and Attanuator) is known in measuring code. There is no well defined place where measuring ends and machine-control software starts. Logical to Physical translation is desired.

1.5.2. The IMeasure interface depends on CalibrationDataContainer. It relays on EC structure and the measuring code needs a lot of adminstration (keys) to retrive the richt calibration data.

1.5.3. Sensing equipment constants are used directly outside sensing softweare. This causes undesired dependencies. E.g. Sensing is not able to change code without lots of effort and risk.

1.5.4. Metadata on images are used as an interface to get acquire information. This causes undesired dependencies. E.g. Sensing is not able to change code without lots of effort and risk.

1.5.5. There is lots of common substrate-processing and measuring code that must support 2X0, 350 and 375 scenario's. Lots of this generic code currently depends on discrete filters.

1.5.6. Lots of measuring code queries "sensing" for machine related information. But that software also is expected to work on a ORC.

2. Decisions and reasoning

2.1. There are generic components that need to be agnostic to LPPS filter or CL light (called sensing-light).

2.1.1. CD, Focus and uDBF recipes only contains discreet LPPS filters.

2.1.1.1. On 375, discrete LPPS filter mapping to CL light is needed (somewhere).

2.1.1.2. On 350, mapping to continuous and back to discrete could be needed.

2.1.2. uDBO and OV have both discrete and continuous recipe's.

2.1.2.1. Either, generic components need to be agnostic to 350 / 375. Then recipe's needs to be converted to a continuous sensing-light and passed around.

2.1.2.1.1. On 375, continuous sensing-light needs to be converted to machine CL light in substrate-processor.

2.1.2.1.2. On 350, continuous sensing-light needs to be mapped to machine LPPS filters in substrate-processor. (Only allowed for exact matches)

2.1.2.1.3. A default static mapping continuous <-> discrete is needed.

2.1.2.1.4. Bennefit

2.1.2.2. Or, generic components pass around sensing-light that is either continuous or discrete.

2.1.2.2.1. On 375, conversion to machine CL light depend on discrete and continuous sensing-light in substrate-processor.

2.1.2.2.2. On 350, only discrete sensing-light is allowed to be mapped to machine LPPS filters in substrate-processor.

2.1.2.2.3. Extra problems

3. Solutions

3.1. Split SensingLight into new types

3.1.1. Make static code analysis possible, in order to find places to change.

3.1.2. Find invalid conversions  easy.

3.1.3. Easier  to refactor code.

3.1.4. Better dependency management between FC's.

3.2. Extend or create new IMeasure interface

3.2.1. Provides images, calibration data and acquire information (e.g. actual wavelength) as one package.

3.2.2. It will make a lot of undesired interfaces obsolete. (equipement-constants, image-metadata, GetActualWavelength, GetAvailableSensingLights, etc.)

3.2.3. Stages

3.2.3.1. Implement new IMeasure interface without changing the behavior.

3.2.3.1.1. Split SensinfImageData and implement the IAcquired...SensingData

3.2.3.2. OV / uDBO

3.2.3.3. CD

3.3. Create a Machine Conversion interface with different implementations for 350 and 375.

3.3.1. It is able to convert the logical-aperture and application-sensinglight to the physical/machine acquire settings.

3.3.2. It acts as the bridge between measuring and sensing.

3.4. Remove all usages of equipment constants. Exceptions in sensing: calibration-data-handlers, settings-provider, 2X0 only code.

3.5. Remove all usages of image-matadata. Exceptions in sensing: acquirement-result-publishers (reading an entry should not exist)

3.6. ?? What to do with existing proxies. Create new usage focused WCF-services / Proxies / components.

3.7. Remove usages of sensing proxies. (First from ORC, then other configurations)

3.8. ACPD's (Adjustment, Calibration, Performance, Diagnostics)

3.8.1. Create a component that provides default set of ExternalSensingLights for which the sensor / machine needs to be calibrated.

3.8.1.1. 350 implementation returns the available LPPS filters. (discrete sensing-lights)

3.8.1.2. 375 implementation returns a set of CL wavelengths that resembles the LPPS filters.

3.8.1.2.1. Spec-checker only stores these well known wavelengths.

4. Use cases and system varibility

4.1. Measure a wafer

4.1.1. Recipe is converted into an logical acquirement

4.1.1.1. recipe to logical aperture

4.1.1.2. recipe to application-sensinglight

4.1.1.3. ...

4.1.2. Processor translates logical to physical

4.1.2.1. logical-aperture to physical-aperture

4.1.2.2. application-sensinglight to machine-sensinglight

4.1.2.3. ...

4.2. Edit a recipe

4.2.1. Check if acquiring is posible

4.2.1.1. logical-aperture to physical-aperture

4.2.1.2. application-sensinglight to machine-sensinglight

4.2.1.3. ...

4.3. Calibrate sensor

4.3.1. Get a set of physical-apertures to calibrate

4.3.2. Get a set of machine-sensinglights to calibrate

4.3.3. Get a set of ...