1、Copyright Government Electronics constructs, such as net, appear in italics throughout this volume. Whenever more detail is desired about a topic the italicized constructs should be consulted in the EDIF Reference Manual. The EDIF Reference Manual contains the official definition of the format and s
2、hould always be taken as the authoritative source of information. Further application guides will be provided in later volumes of this series. Copyright Government Electronics : circuit designer and customer of CAE/CAD system and foundry service can expect compatibility among these products. The des
3、igner can choose equipment and services best suited for a particular task with a minimum of overhead. Foundries can work with customers regardless of the CAE/CAD equipment that the customer is using. The CAD/CAE tool or system vendor can maintain compatibility with a variety of foundries and other s
4、ystems with a minimum investment in spftware development for that purpose. Many interchange formats and hardware description languages have been developed over the past decade. However, each has suffered from one or more of the following drawbacks: 0 Narrow focus - many formats have been developed t
5、o address only a specific aspect of the design data, such as mask artwork data or netlist information, but not both. 0 Proprietary constraints - many formats are proprietary to specific semiconductor or CAD companies, severely limiting their effective use. 0 Difficulty of Implementation - often, as
6、a format evolves, it becomes increasingly difficult to develop parsedgenerator software for dealing with it; this is particularly true if upward compatibility is an issue. 0 Difficulty of Extension - the rapid evolution of IC and PCB design methods causes new facets to be added to the data that must
7、 be transferred. Many languages or formats cannot grow to meet these new needs. The Electronic Design Interchange Format has successfully addressed all of these problems and has made the movement of all design data a reality. i Copyright Government Electronics the layout and schematic views also des
8、cribe other aspects of the circuit. The way in which the connectivity of a circuit is described is common to all such views. 1.2 Hierarchy and Nets EDIF supports a hierarchical description of a circuit. The circuit is broken down into a number of cells, various aspects of which are described in view
9、s. A view may instantiate other views, forming a hierarchy. Within a view, the instantiated views of other cells may be regarded as black boxes or components which are connected together in some way. When describing a view, we are less interested in the contents of the instantiated views than in the
10、 interface of those instantiated views. EDIF supports this abstract approach by dividing a view into two parts: the interface and the contents. The interface describes an abstract representation of the view which may be visible when that view is instantiated within the contents of other views. One a
11、spect of the interface is that it describes what the view looks like when viewed from the outside; that is, it describes its shape and size and also the points to which connections can be made. These connection points are called ports by EDIF and represent the only places where a connection can be m
12、ade between the contents of a view and its external environment. When a view is described, we must define an interface with some ports; otherwise we cannot connect to the view. We may also describe the view itself in the contents. When another view is instantiated within the contents we are describi
13、ng, we may also be able to connect to that particular instance. We can think of the instance importing copies of the ports in its definition into the instancing view. 1-1 _ Copyright Government Electronics the ports are shown as shaded rectangles within the boundary of a view. master ports O instanc
14、e ports I Figure 1. Master and instance ports. For the connectivity of the circuit to be described we must have some mechanism to reference ports. This is achieved using the portRefor gZobaZPortRefconstructs. In the case of a master port we simply have to name the port within the portRef. For exampl
15、e, to refer to master port MP we would write: (portRef MP) In the case of an instance port, we must qualify the name with an instance name. For example: (portRef A (instanceRef I) means port A of the instance I. On occasions it would also be useful to refer to all the ports with a particular name on
16、 all of the instances. EDIF provides a shorthand for this in the form of the gZobaZPortRefconstruct. If we have two instances, I1 and 12, each with a port GP, and anotherinstance I3 without this port GP then 1-2 Copyright Government Electronics it has no implications beyond its use as a shorthand no
17、tation. Within a view some of the ports could be connected or shorted together. If the circuit is considered to be a number of components wired together, there could be a piece of wire joining the connected ports. Since in an EDIF description of a circuit we are taking a hierarchical view, we only n
18、eed to consider the description of these connections within the contents of one view. All the connected ports lie within a net. A net is the set of ports which are directly connected together, with associated attributes and possibly corresponding graphics. For example, in Figure 3 there are six nets
19、, five of which include master ports and one, net4, which consists only of a pair of instance ports. 1-3 Copyright Government Electronics that is (member busPort O) comes before (member busPort i), and in the case of portBundZes, the order is specified by the order in which the component ports are l
20、isted. In clocks above, clkl precedes clk2. In the case of arrays with multiple dimensions, the ordering is defined such that the first index varies most slowly. For example: Copyright Government Electronics therefore each port must be a compound port with four members. Since all compound ports are
21、ordered as described earlier, we may use a mixture of references to array ports and port bundles, provided they each have four members. The connectivity is then defined by the ordering of the member ports in the array or bundle: the first members are joined, the second members are joined, and so on.
22、 Copyright Government Electronics one port would be used in full in the array net, and a member of the other port would be used in the single net. That is, the ripper definition would become: 1-13 Copyright Government Electronics this is true because we only take a local, and not a global view of ne
23、ts in this context. Copyright Government Electronics & Information Technology Association Reproduced by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-EIA EDIF*2 9 = 3234600 0001302 T Volume 2 EDIF Series Figure 13. External connections
24、 of joined ports to two nets. 1.8 Weakly Joined Ports A closely related construct in the interface is the weakJuined construct. It is similar to the joined construct in meaning with one important exception. Ports appearing in the weakJuined construct are connected internally so that an external conn
25、ection can be made to any one of them, but they cannot be used as feedthroughs (forming part of the routing of the external view). If the interface above had been described as (interface (port JI) (port J2) . (weakJoined (portRef Ji) (portRef 52) then the feedthrough implied by Figure 13 would not h
26、ave been valid. As well as joined and weakJuined, EDIF also allows a mustJuin construct to be used in the interface. Ports referenced in a mustJuin must be connected externally. If the interface was described as (interface (port A) (port B) (mustJoin (portRef A) (portRef B) then the nets must be connected as in Figure 14 for the circuit to operate correctly, 4 a i 1-22 Copyright Government Electronics & Information Technology Association Reproduced by IHS under license with GEIA Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-
