AIF III is the third version of the AIF database which was originally developed by Amkor and Artwork conversion. Artwork has continued to extend and improve the AIF format, releasing version II in 2000 and now version III in 2002.

Version III was developed because the earlier versions were simplified by making many basic assumptions:

• one die, one package
  
• die centered on package
  
• die not rotated
  
• no concept of layers or stackup
  
• no concept of circuit traces or vias
  

While these assumptions simplified the database making it possible to hand edit and manually create an AIF file with a spreadsheet it did limit what could be represented. For example, one could not support two die in a single package, or even a die placed off center.

To overcome these limitations we studied existing database of various package design tools and came up with a fully hierarchical database that included all of the basic constructs one finds in a typical package design: layers, traces, metal areas, vias and padstacks.

Of course, this new database is much more complex and it is unlikely that anyone will be building AIF III files with a spreadsheet. However AIF III can easily describe structures such as stacked die, MCMs and flipchips (including the IO buffer on the chip).

AIF Structure

The new AIF format is based upon a hierarchical structure defined by parentheses. An open parenthesis followed by a single keyword containing no white-space defines a new level of hierarchy. An open parenthesis followed by a keyword, white-space, then data indicates a property of the current level and should be followed by a closed parenthesis. All new levels of hierarchy should also be followed by a closed parenthesis, after all properties have been defined. All other white-space, including newlines is ignored. The new AIF format is not case-sensitive. E.g. The following are all equivalent.

(AIF                       (AIF (Version 3.0))            ( Aif
 (Version 3.0)                                            ( VERSION      
)                                                             3.0
                                                           )
                                                           )

Text properties may be quoted using a single quote and text properties containing white-space must be quoted. Comments may be placed at any level using the Comment keyword. E.g.

(AIF
 (Comment IDoNotNeedToBeQuoted)
 (Comment 'ButIMayBeQuoted')
 (Comment 'I Do Need To Be Quoted')
 (Comment 'The only illegal character (at this time) is the single quote')
)

Real and integer properties should not be quoted.

All AIF objects of the same type and at the same level require a unique Name property. If a name is not provided, one will be assigned when the file is converted into a virtual AIF model. All AIF objects are referenced by this name. So, for purposes of connection, assignment and reference, this name must be defined. Some objects have a Number property which is not required to be unique or non-empty and provides for more flexibility. This will be described in detail later.

This covers the basics of the AIF structure. The actual AIF objects will be described next.