GB/T 35010.2-2018Semiconductor die products -- Part 2: Exchange data formats (English PDF)

5.4 DDX files and its data should be independent of the computer and operating system.

5.5 DDX file content should contain mechanical and interconnection information, but can also contain electronic and functional data.

5.6 DDX files may contain data for one or more devices and shall be used as a repository file for the CAD/CAE software design system.

A DDX file can contain one or more sets of data for the same device type, each with a different transfer mode, such as bump chips, bare chips, and cores.

Chip-level packaging.

5.7 DDX files should be able to be generated simply or automatically, for example via an ASCII text editor or spreadsheet software.

5.8 DDX files should be able to reference some external files, such as simulation and thermal model files.

5.9 All data should be defined in a way that can be converted to and from other exchange formats, such as chips such as GDSII and CIF.

Geometric data. In order to support the simple conversion of some DIE (Chip Information Exchange) data files, compatibility with existing DIE data is required.

May be close.

5.10 The parameter definition shall be consistent with GB/T 17564.4-2009 (see Chapter 5 of IEC 62258-1).

6.1 Data validity

6.1.1 All data that does not follow the data syntax rules (see 7.3) should be treated as comments and will therefore be ignored.

6.1.2 All mandatory data should be defined before use. Undefined data should indicate an error and the display data is not available.

6.1.3 Mathematical operations, calculations or formulas shall not be allowed to appear inside digital data.

6.2 character set

6.2.1 The DDX file should be an ASCII-compatible text file with an appropriate line terminator. Line terminator

System decision. DOS/Windows generally uses the carriage return/line feed "CR/LF" as the terminator (ASCII0Dh/0Ah), however UNIX

The system generally only needs the newline character "LF" (ASCII0x0A), and the carriage return symbol "CR" (ASCII0x0D) is the default and will not be displayed.

6.2.2 The fields allowed for ASCII characters are 0x00~0x7F, and the remaining parts from 0x80~0xFF should be ignored.

6.2.3 All text data should be case-independent.

6.2.4 Space characters (ASCII20h) and tabs (ASCII09h) should be treated as delimiters. Multiple spaces and tabs are considered syntactically.

Make a separate separator.

6.3 Grammar rules

6.3.1 All data lines shall be terminated with a semicolon ";".

6.3.2 The comma "," shall be used as the data separator.

6.3.3 with the symbol "

In a separate file. Each DEVICE block is unique and should contain only data about one device and has specific

Device format. All data within each DEVICE block shall be considered local and unique only within the current block (see 6.3.4).

7.1.2 Parameter Type

There are two types of parameters for data, structure, and variables, and these parameters should only appear inside the DEVICE block.

* A structure determines a collection or a collection of data with different data types;

* A variable is equivalent to one or more data of a single data type.

7.1.3 Data Type

The data types are as follows.

7.1.3.1 Text string data

All ASCII characters from 20h to 7Fh are allowed in text data, while characters of ASCII80h and above should be ignored.

In order to be able to print underlined or underlined characters, special printing or display control characters can be considered. It is recommended to place text string data

In pairs of double quotes, see 6.3.7.

7.1.3.2 Text Name Data

All names should be unique and should consist of only the following character sets from ASCII.

A~Z a~z 0~9 $ - %

When text name data is used as the constituent file name, it is recommended to limit the file name to 8 characters and the file extension limit

Within 3 characters, the two are separated by a separator ".", which is consistent with the general operating system. It is recommended to place the text name data in

In pairs of double quotes, see 6.3.7.

It is worth noting that all text name data is case-independent, and no space characters are allowed in a text name.

7.1.3.3 Real data

The real data representation shall be consistent with SJ/Z9047-1987 and shall consist of the following characters.

0~9 - .Ee

Values can be positive or negative, expressed in engineering or scientific notation, but should not contain orders of magnitude. E.g.

90008, 9000.80, 9.0008E5, -5207, -5.207E3, 0.102, 102E-3

Note that the comma "," here is used as the data separator, so the decimal point "." should not be used instead.

7.1.3.4 Integer data

The integer data value should be consistent with SJ/Z9047-1987, and only characters 0~9 are allowed. Integers should have no positive or negative points and should not be included

Contains orders of magnitude.

In combination with the actual situation, the integer should be limited to 16 bits, for example, only 0~65536 and the integer values including 0 and 65536 are connected.

Accepted.

7.1.3.5 Date data

The date data value should be consistent with GB/T 7408-2005 and can include time information. E.g.

"YYYY-MM-DD", "YYYYMMDD", "YYYY-MM-DDTHH.MM.SS".

7.1.4 Forward reference

To allow one-way parsing, all variable identifiers or variable names should not be referenced before they are defined.

7.1.5 units

All units shall be in the International System of Units except for the geometric units of micrometers (10-6 m), inches and mils (10-3 in). In a separate

In the DEVICE block, there should be only one order of magnitude. It is worth noting that inches and mils are not recommended units, they are only

Some continuation of idioms appears.

7.1.6 Coordinate data

In all coordinate data, the X coordinate should be before the Y coordinate, and the Y coordinate should be before the Z coordinate (for example, X, Y or X, Y, Z).

The X coordinate should be the horizontal axis (the number increases from left to right), the Y coordinate should be the vertical axis (the number increases from bottom to top), and the Z coordinate should be deep

Degree axis (numbers increase from near to far).

7.1.7 Reserved words

All parameter names should be treated as reserved, no variable identifiers or scalar names should be allowed to have the same name. But this restriction is in the band

Invalid text data with quotes or double quotes (see 7.1.3.1 and 7.1.3.2).

7.2 DDXDEVICE block syntax

DEVICEdevice_namedevice_form {

Device related data

A DDX file can contain one or more DEVICE blocks, and all data for a particular device should be embedded in the relevant block (see 6.1.1).

And 7.1.1).

A DEVICE block begins with the DEVICE keyword and the leading braces "{" (shown above) with the corresponding back braces "}"

End.

Data not included in the DEVICE block structure should be treated as a comment, allowing future verification information, file creation date and history to be added in the future.

Data, etc., this information is in the DDX file and therefore does not affect the actual device data.

Device_name represents the name of the device that should be referenced, and device_form represents the mechanical form of the device to which the block data belongs.

The variable device_form represents the type of device being referenced, including.

* bare chip;

* bump chip;

* There are lead frame chips;

* The smallest packaged device (or MPD).

More device_form types can be added later, see GB/T 17564.4-2009, AAD004-001, "Chip Types" for more details.

coding".

Only one DEVICE block with device_name of type device_form should appear in a DDX file, but duplicate

Device_name or device_form is allowed.

An example of a typical DDX file convention for a DEVICE block.

DEVICEname1bare_die{

relevantdataforDEVICE "name1" asabaredie.

DEVICEname1bumped_die{

relevantdataforDEVICE "name1" asabumpeddie.

DEVICEname2mpd{

relevantdataforDEVICE "name2" asaminimalypackagedDEVICE.

DEVICEname2bare_die{

relevantdataforDEVICE "name2" asabaredie.

DEVICEname1mpd{

relevantdataforDEVICE "name1" asaminimalypackagedDEVICE.

DEVICEname3bare_die{

relevantdataforDEVICE "name3" asabaredie.

In the above example, there are three occurrences of the DEVICE block of the device "name1", and two types of DEVICE blocks of the device "name2" appear.

Situation, but each shows a different device_form. The order of the DEVICE blocks is not relevant.

7.3 DDX data syntax

Property=value[,value];

\u003cproperty\u003e [equateseparator] \u003cvalue/variable{separator\u003cvalue/variable\u003e } >[dataterminator][line

Terminator]

\u003cproperty\u003e ..= Parametername

[space] ..= {spacecharacter(20h)ortabcharacter(09h)}0

[equateseparator] ..= [space]{equal=}[space]

[separator] ..= [space]{comma,}[space]

[dataterminator] ..= [space]{semicolon;}

[lineterminator] ..= CRorCR/LF}

Example.

Thickness = 100.0;

Thickness=470;

Geometric_units=micron;

Geometricunits = micron;

GeometricUnits= "milimetres";

Terminal_type= T1,Circle,220;

Terminal_Type= T2, Rectangle,.200, 250;

TerminalType= T2, O, (200, 250);

TERMINALTYPE = T2, O,.200, 250;

As shown above, terminal_type, Terminal_Type, TerminalType and TERMINALTYPE will all reference the same parameter.

Number name.

8.0 General Usage Guide

8.0.1 Device Form Guide

When the device_form of a parameter is unique, the prefix of this parameter is as follows, as defined in the DEVICE block.

8.0.1.1 The DIE_ data parameter refers to the bare chip or bump chip form.

8.0.1.2 The BUMP_ data parameter refers only to bumped chips.

8.0.1.3 MPD_ Data parameters refer to the smallest packaged device, such as CSP.

8.0.1.4 WAFER_ Data parameters refer to wafer level chip device delivery.

8.0.1.5 The LEAD_ data parameter refers to a chip device with a lead frame.

8.0.2 Data Parameter Terms

In the directory of data parameters (see 8.1), the relevant terms are as follows.

8.0.2.1 Parameter name, used as a statement in the DDX file.

8.0.2.2 Parameter type indicating a variable or structure data type.

8.0.2.3 Parameter function determines its usage and meaning.

8.0.2.4 Parameter value indicating the required data type.

8.0.2.5 Any parameter restrictions indicating any restrictions within the DEVICE block.

8.0.2.6 Parameter dependencies, emphasizing the parameters that need to be defined before the call.

8.0.2.7 One or more practical examples.

8.0.2.8 Other relevant notes.

Appendix F provides a brief parameter table, Appendix A provides a complete DDXDEVICE block working example, and attached

The required image output is provided in Record C.

All parameters shall be consistent with the GB/T 17564.4-2009 Data Element Type (DET) code, which is coded in GB/T 17564.4-

Defined in.2009. See Appendix F as a search form.

8.0.3 Terms and conventions

An electrical connection point is called a terminal. This can be a bonding area of a bare chip, or equivalent to the need to interconnect media

The desired landing point or connection coverage area. The general rule of the chip is that the top left corner of the chip has a start number labeled 1, and other references

The output or pin number is incremented in a counterclockwise direction.

The X-axis coordinates represent the length of the horizontal plane and increase from left to right in positive numbers. Y-axis coordinates represent the horizontal plane width, with a positive number

Forms are incremented in a way that is far from the user's perspective. The Z-axis coordinates represent the vertical height and are incremented from bottom to top in positive numbers (for observers)

Direction).

As a point of reference, all chip components, including bumped chips, are typically viewed from above the active area.

8.0.4 Description of general rules

8.0.4.1 All valid data shall be included in the DEVICE block (see 7.1.1).

8.0.4.2 Any local or unique parameters, such as names, should be defined prior to use.

8.0.4.3 All parameters shall be consistent with the GB/T 17564.4-2009DET code, which is coded in GB/T 17564.4-2009

Definition (see 5.8 and Appendix F).

8.0.4.4 The unit of measure GEOMETRIC_UNITS shall be defined before any geometric variables are defined.

8.0.4.5 Geometric origin GEOMETRIC_ORIGIN and geometric perspective GEOMETRIC_VIEW should be before any geometric coordinates are defined

Define first.

8.0.4.6 The TERMINAL_COUNT parameter shall be defined before any TERMINAL parameters are called, and the TERMINAL parameter

The number should not exceed the value of TERMINAL_COUNT.

8.0.4.7 The TERMINAL_TYPE_COUNT parameter shall be defined before any TERMINAL_TYPE parameter is called, and

The number of TERMINAL_TYPE parameters should not exceed the value of the parameter TERMINAL_TYPE_COUNT.

8.1 block data

8.1.1 DEVICE_NAME parameter

It is defined in the DEVICE block header by the device_name parameter.

Parameter name device_name

Parameter type variable, see 7.2 About DEVICE block content

The parameter function defines the device manufacturer's type number or reference name

Parameter value text name data, such as 7.1.3.2

Example. SN74LS04

See 7.1.7, 7.2 and Appendix G for reference.

8.1.2 DEVICE_FORM parameter

The device type is defined by the device_form parameter in the DEVICE block header statement.

Parameter name device_form

Parameter type variable, see 7.2 About DEVICE block content

Parameter function defines the physical form of the device

Parameter value text string data, such as 7.1.3.1

Examples. bare_die, bumped_die, MPD.

References 7.2 and Appendix G

8.1.3 BLOCK_VISION parameter

Parameter name BLOCK_VERSION

Parameter type variable

The parameter function specifies the version number or release number of the DEVICE block.

Parameter value text string data, such as 7.1.3.1

Restricted in one.