Some standard content:
FL0138, Military Standard of Electronic Industry of the People's Republic of China
Electronic Design Interchange Format
Electronic Design Interchange FormatPublished on August 30, 1996
SJ 20609-96
Implementation on January 1, 1997
Approved by the Ministry of Electronics Industry of the People's Republic of ChinaForeword
1 Scope
1 1 Subject matter
1.2 Scope of application
2 Referenced documents
3 Symbols
3.1 Character table
3.2 Symbol constants
4 General requirements
4.1 EDIF general syntax
4.2 EDIF syntax
4.3 Names
Representation of names or identifiers
4.3.2 EDIF 4.3.5 Renaming for external use
4.4.3 Boolean
4.4.5 Number distinction...
5 Detailed requirements
5.1 EDIF Standard Manual
5.2 EDIF Syntax
5.2.1 Introduction
5.2.2 Symbolic representation
5.2.3 Level 0
5.2.4 Level 1
: (10)
TYKAONKACa-
5.2.5 Level 2
5.2.6 Keyword Level 1
5.2.7 Keyword Level 2
5.2.8 Keyword Level 3
Appendix A Chinese-English Vocabulary
This standard is equivalent to the American national standard ANST/FIA-548-1988\Electronic design interchange format Version 20o\, so the technical content is consistent. According to the (Interim Provisions for the Preparation of National Military Standards), major changes have been made in the format to make it more organized. The specific changes are as follows: a. The contents of Chapter 1 and Chapter 2 are added; b. Article 3.1 of Chapter 3 corresponds to Chapter 4 of the original standard, and Article 3.2 corresponds to Chapter 5 of the original standard; Chapter 4 corresponds to Chapter 1 of the original standard, among which Articles 4.1 to 4.4 correspond to Articles 1.1 to 1.4 of the original standard respectively. In order to make the text of the standard eye-catching and clear, the third level of article numbers is added, that is, 4.3.1 to 4.3,5 and 4,4.1 to 4,4,5 are used as the corresponding titles. d. Article 5.1 of Chapter 5 corresponds to Chapter 2 of the original standard, and Article 5.2 corresponds to Chapter 2 of the original standard. Articles 5.2.1 to 5.2.8 are added, corresponding to Articles 3.1 to 3.8 of the original standard respectively. e. The publication instructions in the original standard are deleted in this standard. f. An appendix is added - Chinese-English vocabulary comparison. YKAONKAca
People's Republic of China Electronic Industry Military Standard Electronic Design Interchange Format
Electronic Design Interchange Format1 Scope
1.1 Subject Content
SJ 20609-96
This standard specifies the design interchange format (EDIF) interface in the process of electronic automatic design and manufacturing. 1.2 Scope of Application
This standard applies to the design of electronic and computer products, including electronic information systems, electronic circuits (digital, analog), printed circuit boards (PCB), programmable devices, integrated circuits (IC, including special integrated circuits), etc. When electronic design automation (EDA) tools are used for the above design, it is used as a standard in the following occasions: a. Circuit netlist (Netlist) level design exchange format: physical layout (IC, PCB) level design interface; b.
c. Behavioral description of electronic systems;
d. Interface between computer-aided design (CAD) and computer-aided manufacturing (CAM); design data exchange between EDA tools or designers. e
2 Quoted Text
No clause in this chapter
3 Symbols
3.1Character table
Code:
Character:
Used for:
Ministry of Electronics Industry of the People's Republic of China Issued on August 30, 1996 Note
Implementation on January 1, 1997
Code:
Character:
Used for:
whiteSpace
whiteSpace
whiteSpace
SI 20609-96
specialCharacter
siringTokenquote
specialCharacter
specialCharacter
asciiCharacter percent
identifiet and specialCharacterspecialCharacter
farm and specialCharacter
form and specialCharacter
specialCharacter
integerToken and specialCharacterspecialChararter
back space
horizontal tab
line feed
vertical tab
form feed
carriage return
blank space
ampersand
left parenthesis
right parenthesis
plus sign
TTTKAONKAca-
Code:
Character:
Used for:
SJ 20609—96
integerToken and specialCharacterspecialCharacter
specialCharacter
specialCharacter
specialCharacter
specialCharacter
specialCharacter
specialCharacter
specialCharacter
specialChnracter
minus sign | | tt | specialCharacterspecialCharacter
underscore
KAONKAca-
Code:
Character:
Symbol constant
Symbol constant:
REHAVIOR
CALCULATED
CAPACITANCE
CENTERCENTER
CENTERLEFT
CENTERRIGHT
CHARGE
CONDUC TANCE
CURRENT
DISTANCE
DOCUMENT
ENERGY
EXTEND
FREQUENCY
GENERIC
GRAPHIC| |tt||INDUCTANCE
LOGICMODEL
LOWERCENTER
LOWERLEFT
LOWERRIGHT
MASKLAYOUT
Used for:
SJ 20609-96
specialCharacter
specialCharacter
specialCharacter
specialChatacter
is used for:
viewType
derivation
justify
justify
justify
viewType
cornerType and endType
cellType
viewType
direction
direction
viewType
justify
justify
justify
viewType
Symbolic constants:
MEASURED
NETLIST
OUTPUT
PCBLAYOL T
REQUIRED
RESISTANCEwww.bzxz.net
RIPPER
SCHEMATIC
STRANGER
SYMBOLIC
TEMPER ATURE
TRUNCATE
UPPERCENTER
UPPERLEFT
UPPERRIGHT
VOLTAGE
4 General Requirements
SI 20609-96
for:
derivation
orientatian
brientation
orientation
orientation
viewType
direction| |tt||viewType
orientation
orientation
orientation
orientation
derivation
cell'Type
cornerTypeand endType
viewType
viewType
viewType
cellType
cornerType and endType
justify
justify
justify
This chapter gives an overview of the basic concepts of EDIF. Including the level of EDIF, as well as the syntax and overall syntax used in the file. The concepts described in this chapter are applicable to all levels of EDIF. Including converting the final data form of the mask wiring diagram, as an exchange format for electronic design data, it should meet the needs of various users, and converting the behavioral description of the microcomputer. Although the programmatic format can be used to describe the mask wiring diagram data, the data can be more effectively represented using simple geometric primitives. The basic requirement for the conversion format is to be able to clearly and accurately describe the transmitted data. In this way, the writer and reader of the format have accurate and consistent interpretations of the file. In order to avoid complicating simple issues and to provide some users with the ability of programmatic description, EDIF descriptions can be specified at three different complexity levels, namely: SJ20609-96
TKAOIKAca-
0Level: Basic level - only text constants are allowed: Level 1: Add parameters and expressions based on Level 0: Level 2: Add control flow components based on Level 1. Because Level 1 is a proper subset of Level 2; Level 0 is a proper subset of Level 1, to go down a level, you only need to evaluate the functions and expressions and replace the parameter values with constant values. This conversion is required when advanced design environments become simpler systems, and parameter information will be lost. The title bar in the standard book gives the EDIF level in parentheses: <0>; <1>; or <2>. If not given, it means that the component applies to all levels. Similarly, it is divided into according to the abbreviation of the keywords in the component.;;as well asThere are four keyword levels. They represent no abbreviation; simple keyword abbreviation; non-alternative keyword definition and alternative keyword definition.
4.1 EDIF General Syntax
The general syntax of EDIF components described in the following clauses follows the following rules: a. Syntactic classes (non-terminal symbols), literal words and characters (terminal strings) remain unchanged in their English original form. Symbol constants are represented by uppercase English letters; single characters are represented by + and bracket symbols represent brackets. b. Components enclosed in square brackets [] indicate that it is an optional item. c. Components enclosed in curly brackets 》{ indicate that it can be repeated ○ times or more in any order. d. A vertical bar indicates a choice, and only one of the optional items can be selected. A list of items enclosed in curly brackets 1!, if separated by vertical bars, means that each item can appear any number of times, and the order between items is also arbitrary. In such a list of items, if there is an item that can only appear once, it is enclosed in angle brackets <>.
, the notes on the right side of the text are comments, which are not part of the syntax. ". Ellipses.. indicate that the subsequent items in the example are omitted.: All EDIF names must be defined before they can be referenced. 4.2 EDIF Syntax
EDIF uses a syntax similar to Lisp. The principle of establishing syntax is to facilitate analysis and provide a unified method for extending the format. A component begins with a left bracket and a keyword, followed by a series of items, and finally ends with a right bracket. These items can be other components, forming a nested structure: or some tokens composed of data items, such as integer tokens, string tokens, or EDIF identifiers. Delimiters can be used on either side of the brackets in EDIF components, but they are not required. Use. EDIF delimiters are ASCII characters, such as space, tab, carriage return, and line feed. In this document, a series of legal identifiers are defined as keywords in EDIF. Users of the EDIF format can define their own keywords based on existing EDIF keywords using the components KeywordAlias and KeywordDefine. Case is not important in keywords, symbol constants, or identifiers. Explanatory points about specific components are given between the two hyphens and in the following paragraphs. 4.3 Names
4.3.1 Representing Names or Identifiers
In EDIF, identifiers are used to uniquely identify different targets. FDIF does not attach any SJ to the spelling of identifiers. 20609-96
Specific meaning. If a number of identifiers are uniformly rewritten as new (valid) identifiers, including the original naming definition and all occasions where the identifier is used to represent the object, the basic semantics of the EDIF file remains unchanged; the structural semantics should be the same, and only the form of the name itself should change. No meaning should be assumed or expected when choosing a name. This is in sharp contrast to the keywords (and symbol constants) defined by EDIF itself. The full semantic meaning of these keywords is given in this manual.
4.3.2 The role of names in EDIF
EDIF uses two mechanisms to express the relationship between hundreds of standards: containment and name reference: containment is purely A lexical mechanism that involves the textual inclusion of an object, where the object's description is contained within a pair of brackets within another description (component). Many relationships can be expressed simply by inclusion, such as a cell's definition being part of a library, and a view being contained within a particular cell. However, inclusion itself is only suitable for describing simple one-dimensional structures. There are many relationships between objects in a typical CAD database, requiring greater flexibility, such as representing netlist connections and referencing one cell in another. The details of the naming structure specified by EDIF come from the need to express such relationships on the one hand, and also from some naming conventions commonly used in typical CAD systems on the other hand. For the initial naming process, as few restrictions as possible are imposed. To this end, reserved identifiers are provided in EDF.
To make the format clear, different categories of objects, such as cells, ports, and nets, are not related to each other when naming. For example, a port is described as the name of a cell, which does not mean that there is any semantic relationship between them, but is just a coincidence in spelling.
Another important aspect of the naming mechanism is that names must be defined before they are referenced. Very few design systems use an unfolded flat naming scheme. In this case, the name is used only within a fully defined scope. For example, the name of a port in a unit cannot be confused with the name of a port in another unit, even if they do have similar spellings. Such local names must be qualified before they can be referenced elsewhere. For example, in order to use an example port, not only the example name is required, but also the port name in the unit definition. 4.3.3 Name categories
An essential issue in EDF self-reference is the name type. The national standard type of the name determines the category of the name, such as the unit name or the logical value name, and when the identifier is referenced, it is linked to the target category through the subsequent text content.
The different name types are parallel and the naming method is independent, all subject to the same scope rules. Even if these names occasionally use the same identifier spelling, or even have overlapping ranges, there is no connection or interference between them. In addition, these categories are not inconsistent with identifiers used as keywords or symbolic constants: a unit is named an or even cell, but it does not mean that it has any connection with the corresponding keyword. Some name categories are used in several keywords, for example, external and library both define the name of a library. 4.3.4 Name scope (bound)
The scope of a name is usually defined by the lexical containment within a certain component, such as library, cell, or view. The direct scope of a named target starts from the description immediately after the name and ends before the smallest ending bracket of the name scope. Two names of the same category, such as nested names and the same scope, are not allowed to be assigned the same name. For example, two cells in a library cannot have the same name. The following example illustrates the main name scopes established in EDIF. (edif example
(edif Version 200)
HTTKAONKAca
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.