Zenpire  Products 
  iFAB-Defect
  iFAB-Test   
  iFAB-Setup    
  iFAB-Bit 
  iFAB-Pixel
  iFAB-Utilities   
  iFAB-Central 
  iFAB-FA                                                  

Most of the iFAB modules can survive as standalone applications reading in setup and data files to perform analysis and visualization. iFAB-Central represents the backbone of the iFAB product line. Its main objectives are to be a data loader and mover, information messenger, and database manager.

iFAB-Central can monitor a directory for files, parse them and disposition them based on content and other rules. File dispositions include deleting, moving, renaming, copying, compressing, and encrypting. iFAB-Central can parse header information from the data file and dynamically create a flat file database using a directory hierarchy based on a file path template created by the administrator. For example, a directory could exists for each lot number, within each directory a sub-directory exists for each wafer id, within each sub-directory another sub-directory is created for each process step. To save disk space securely, each file could be zipped and encrypted using a unique private key stored in an off-line database.

Because iFAB-Central is designed with the Internet and networktivity in mind, there is internal support for several information communication protocols including TCP/IP, HTTP, FTP, UDP and SMB. This means that iFAB-Central is designed to travel across the site's network to put and place files easily.

In keeping with the trend of Internet usage, iFAB loads data into the most popular database of the Internet, MySQL. iFAB-Central stores data similar to the Internet and dissimilar to other commercial yield analysis systems Most yield analysis systems put the burden of data collection, organization, and retrieval in the hands of the database. As databases get larger, related data can physically be scattered around several large hard disks causing for a longer time to recall. Since typical queries for defect and bit map data retrieve data for the entire wafer at once, it seems natural that the data should be grouped together in a single file stream.

iFAB-Central took hints from the largest database every created, the Internet. Why separate defect, test, and bit data so that each defect or bin is a record in a table that will grow to be millions of rows in size? That is like storing every word in this web page as a separate record in a database and then reassembling the sentences immediately prior to viewing. iFAB-Central stores references to the raw defect files and records summary information in the database. This philosophy improves data retrieval performance and guarantees that no data is ever lost during the loading and export processes.

iFAB-Central also provides a graphical tool set to interact with the database. Because JDBC is exclusively used, as different database vendors are accepted by Zenpire Engineering, more choices of databases will be offered including Oracle 8i, Informix, and Microsoft SQL Server. Like all iFAB modules, iFAB-Central runs on most popular computer platforms (Windows 95,98,NT; Solaris; HP-UX; Linux; Apple).

iFAB-Central is not yet released, contact Zenpire Sales for availability.

• Runs on all major platforms
• Easy to use interface
• Utilizes low cost and highly reliable and accepted database MySQL to store references to data files
• Uses JDBC to connect to database, allows future expansion to several database vendors
• Supports connections to several databases across the site's network
• Can run without database by creating a flat file directory hierarchy
• Can perform several operations on files after dispositioning including deleting, moving, renaming, copying, compressing, and encrypting
• Provides graphical interface to database

• Defect engineers looking for a database to store defect files
• Test engineers looking for a database to store test and bit map files
• Analysis software field application engineers looking for a system to cache data during a database upgrade or service

Confronted with collecting and archiving the data coming from the various defect inspectors, defect engineers can use iFAB-Central two ways without ever connecting it to a database. The first is allow the Windows-based inspectors to mount onto it and establish am iFAB-Central loader to periodically check each directory, parse each file and move the file into a directory hierarchy based on process step names, lot ids and wafer ids. The second is to setup a loader to periodically poll the inspector and FTP files from the inspection system into the same same directory structure. iFAB-Central could house the files on its own hard drives or move the files to another file server which has a RAID disk array.

When the defect files are needed, the iFAB-Defect module is used to browse to the files if found locally on the machine or using the iFAB-Utility's FTP client, files are fetched from a remote file server. The organized directory names provides the means to index into this simple "database".

iFAB-Central can be setup to look for files on remote machine or on local directories. If iFAB-Central is installed on a Linux workstation, other UNIX machines can easily mount onto via NFS and Windows machines can mount onto it after Samba is installed and running. Once the testers and inspectors are mounted, iFAB-Central periodically checks for file in the directories. When files are detected, the loader will follow rules that it is given. Files can be moved across the network to one or more other analysis systems, they can be deleted, they can be e-mailed, they can be compressed, or they can be loaded into a database.

iFAB Central acts as the data cache between a costly analysis system and the test floor and fa; acache that can temprarily hold files during a backup or upgrade of the other data systems. Detailed log files are created to confirm actions and to record events. E-mail can be sent to inform key users of operations.