 |
 |
|
|
There are many other considerations in the manufacturing of a circuit besides its mere specification. Data conversion may be required to translate between interchange formats. Testing must be accommodated to verify a circuit and to weed out badly manufactured devices. Also, there are many standard procedures that may be available to speed the design and manufacturing process. This section discusses these side issues that relate to the implementation of VLSI systems.
As this chapter mentioned earlier, interchange formats exist not only to exchange circuits between CAD systems, but also as a path to manufacturing, by converting from one format to another. Therefore one important implementation facility is the ability to translate between formats. When doing so for the purpose of manufacturing, only geometric information needs to be converted, because topology and behavior is not used in fabrication. Nevertheless, a complete conversion system should attempt to retain as much information as possible, in case those data are needed later to reconstruct the original file.
Most geometric format conversion is straightforward and can be accomplished on a figure-by-figure basis. CIF specifies a box by giving its center point, size, and rotation; GDS II describes it with four corner coordinates. Such conversion demands the simplest of algorithms.
A somewhat more difficult conversion occurs when there is no equivalent figure in the other format. Thus the Gerber TEXT commands have no equivalent in CIF and may require a full typeface description so that appropriate geometry can be produced. The same problem arises when converting curved objects to rectilinear ones.
A useful technique in format conversion is to use a third representation as an intermediate. This allows the input file to be read completely before any output is generated, so that all the data can be considered before processing. For example, conversion to CIF needs to examine all coordinate values before choosing scale factors for the CIF cells. Another advantage of using an intermediate representation is that it can be tailored to the needs of the output format. Thus when generating EBES files, an intermediate raster representation helps immensely in handling nonrectilinear shapes such as curves or text. These figures are approximated in the raster array and any overlap is automatically merged. Also, the resulting EBES files need to be sorted and that is much easier when the data are already in a matrix.
Format conversion may deteriorate the data or even fail to work at all. If the unit sizes in the two files are sufficiently incompatible, then the data may have to be approximated. For example, an EDIF file with 200 units to the micron will have to be rounded by one bit when converted to CIF, in which the smallest unit is one-hundredth of a micron. An even more severe problem, however, arises when a CIF cell instance is rotated by 45 degrees. If this CIF file is converted to EDIF version 2.0 or earlier, there will be no way to place the instance correctly, since EDIF cells must appear at Manhattan orientations (this limitation was addressed in EDIF version 3.0). The conversion program can hierarchically flatten the cell instance and describe all its enclosing geometry, or it can simply give up. When conversion degrades or fails, the user should be told of the problem and shown exactly where it has occurred. Conversion must then continue, however, so that unimportant problems do not block the overall process.
Testing is the same as simulating, only it uses real parts rather than software emulation. Some simulators allow actual components to be used for parts of the process, and some testers make use of software models for part of their operation. Therefore it is not surprising that tester formats are often the same as simulator formats. In fact, most testing-machine manufacturers design input specifications that mimic known simulators.
Unfortunately, there are no standards either in simulator commands or in tester specifications. EDIF considers the possibility of tester description but it does not have a complete language for that purpose. A follow-on to EDIF is the Stimulus Data Interchange Format (SDIF), which has similar syntax and attempts to fill the gap in EDIF [Pieper]. Another possible tester standard is CADDIF [Factron], which has been released to the public in an attempt to receive wide acceptance. CADDIF is a binary representation with no control structures: It merely lists the stimulus values to be applied and the expected values to watch. SDIF, however, has the full expressibility of EDIF and LISP, so it is able to describe loops and other concise testing control. SDIF's textual appearance is more flexible than CADDIF's binary structure, which sometimes limits fields to 8 bits and thus cannot express large values.
Tester-interface formats are also variable because of the wide range of testing that can be done to a circuit. Both digital and analog devices must be handled, with tolerances available to capture all the necessary values. For digital circuits, the voltages must be classified according to discrete values of high, low, threshold, floating, and other notions that are digitally described but continuously analyzed. The tester language must therefore speak to all designers in a suitable style. Some tester languages are even able to accept waveforms from the simulator as stimulus and response data.
As the processors in testers grow more sophisticated, they will be able to accept a wider range of test specifications. This will open up the possibility of standard tester formats that cut across manufacturer's limitations.
Another implementation issue that is worthy of consideration is the use of standardized structures on the VLSI chip to ease interface with the outside world. The most common standard structures are the bonding pads, which are provided for each design environment. Use of such pads does more than relieve the designer from bonding considerations such as pad layers and spacing. These standard pads often have necessary circuitry for static protection, TTL driving, and all the analog considerations that are not needed elsewhere on the chip. Thus the digital designer can view VLSI systems in a purely logical sense by using standard parts for the nondigital interface.
One can go even further in providing on-chip standards. For example, it is possible to provide the chip designer with a standard frame of pads, already placed and connected to power and ground. The VLSI designer can then use these pads without worrying about die size or proper pad organization. For maximum flexibility, the pad frame can be a simple template on which real pads are placed. This allows the input, output, and bidirectional pads to appear in appropriate number and location. Power and ground pads can still be fixed as part of the frame, since their locations are often critical and their rearrangement is not necessary to the chip design.
The ultimate on-chip standard is the design frame that includes pads, clock lines, and fully interfaced I/O [Borriello et al.]. The designer is presented with an inner chip area and a set of connection points along the frame. Besides a standard frame on the chip, there is also a standard circuit board outside the chip that correctly interfaces to the bus of a computer. A scheme such as this is excellent for instructional purposes and also provides rapid turnaround for the manufacture and test of prototype circuits. A library of different design frames would be a valuable addition to any CAD system.
The final implementation issue to be covered here is the use of standardized services for the manufacturing of VLSI systems. Earlier sections of this book noted that, in many situations, the manufacturer must be asked to supply the proper mask graphics, compensation, and other specifications for circuit production. However, thanks to our highly specialized and service-oriented society, there are "brokers" that can take care of these details. One such broker is the MOS Implementation Service (MOSIS) which does rapid prototyping of integrated circuits and printed-circuit boards [MOSIS], based on methods developed at Xerox Palo Alto Research Center [Conway, Bell, and Newell].
MOSIS is a service funded by the U.S. government that is available to those people who have received grants from the National Science Foundation (NSF) or the Defense Advanced Research Projects Agency (DARPA). This service is widely used in American universities for implementation of student VLSI projects and faculty research projects. It is also available to other clients who are willing to pay. There are similar services active in other countries, particularly Canada [CMC] and Australia [Hellestrand et al.]. A number of firms offer portions of these services, calling themselves silicon foundries.
MOSIS can accept either CIF or GDS II descriptions. All communication with MOSIS is done by electronic mail. On the Internet, use the address "mosis@mosis.org" or check their web page at "http://www.mosis.org".
Fabricated chips from MOSIS will be placed into varying-sized packages, depending on the pad requirements. MOSIS encourages the use of standard pad frames to make packaging easier, and offers multi-chip modules for combining small projects. This service includes mask-making, fabricating, packaging, bonding, and delivery of chips along with SPICE parameters for the run. The reason that the SPICE parameters are reported with each run is simply that MOSIS is a broker for many fabrication firms and does not know in advance where a chip will be built. Users are assured of high fabrication standards because prototype chips cannot tolerate a low yield. In addition to chips, printed-circuit boards can be manufactured from CIF specifications.
CIF files submitted to MOSIS must meet certain restrictions to enable smooth
fabrication.
The Definition Delete (DD) statement may not be used.
Fortunately, this is usually safe because the statement exists only for
implementors such as MOSIS and is almost never generated by a CAD system.
Polygons must have at least three points, and round flashes must have a nonzero
diameter.
Needless to say, pads must be present in the CIF file, because their location and
number helps to classify the chip automatically.
As an aid to implementation, it is suggested that the "XP" layer be used to
duplicate pad geometry.
GDS II files submitted for fabrication must include the name of the top-level cell, since that information is not part of the data. Users should be cautioned that NODEs, BOXs, and PLEXs will be ignored as will the information in ELFLAGS and ELKEY records.
As it was mentioned before, most conversation with MOSIS can take place electronically. Automatic mail readers know how to respond to messages in the right format, so many requests can be handled without human intervention. Users can obtain documentation, pad-frame descriptions, and even cell libraries containing pads, PLA elements, and so on. It is also possible to submit a chip for fabrication merely by talking to the automatic mail reader at MOSIS. Of course, proper accounting must be established before services can be rendered.
The format of an electronic message to MOSIS is as follows:
REQUEST: keyword
parameters
REQUEST: END
Each REQUEST controls actions to be taken and the message terminates with
an END action.
Messages that have incorrect format will evoke a response that explains the
correct format and gives some initial help.
Thus first-time users of MOSIS can get started simply by sending a message
with any random content.
Requests to MOSIS can be to ask for INFORMATION, to SUBMIT chips,
to demand human ATTENTION, and more.
The options are always growing as the service expands, so consult the
current MOSIS user's manual for details.
|
Previous |  |
Table of Contents | Next | |
Static Free Software |  |