It is true that the quality and success of an analog ASIC generally depends on the specification that is developed for it. A good specification with requirements clearly defined may account for more than 80% of the success, of not only the ASIC device, but also the entire process of development including the business and technical relationship that develops between the customer and analog ASIC vendor.
For it is true that the quality of an analog ASIC is defined by not only how well the device meets the specifications, but also the experience the customer has with the very process of working with the vendor.
It behooves us then, to at least define some basic ground rules for the generation of specifications. It is also true that each analog ASIC will be unique and have its own features, but it is usual for certain items to be included in the specification and follow certain formats.
These issues are explored in this post. We hope this post will be of help to those involved in specifying or implementing an analog ASIC.
This post follows the following outline:
Types of specifications required
Suggested format for the specifications
Challenges in building specifications
1.0 Types of specifications required
In general the specification of an analog chip should be in two parts. The first part is the functional specification and the second part is the test specification.
The functional specification contains a comprehensive description of the chip and all the detailed functionality required by the user. It includes the interaction of the chip with the board ( or substrate ) along with all external components.
The test specification contains the test methods, test options, reliability test options, burn in, thermal operational tests. These numbers and descriptions are usually specified at the I/O of the chip since no other part of the device is available to the outside world.
2.0 Suggested Formats
2.1 Functional Specifications:
2.1.1 The cover page should be the part number of the chip, approvals, revisions and any other high level information.
2.1.2 The next section should provide a clear but brief conceptual level description of the function.
2.1.3 Following the functional description a fairly detailed block diagram with the pin I/O clearly marked should be provided.
2.1.4 A table of pin descriptions should be included which provides clear information on the pin number, the pin name, the pin symbol, whether input or output, and a
succinct description of the function of the pin.
2.1.5 Also included are the absolute maximum ratings for current, voltage, temperature, etc. the chip may be exposed to in extreme cases in a tabular format.
2.1.6 The next section of the specification should clearly describe the principle of operation, timing, flow charts, relevant technical data, operational characteristics etc. in reasonable detail.
2.1.7 Specify the DC operating conditions of the chip including logic levels, power dissipation, supply currents, operating temperature, supply voltages etc. in this section. Minimum, typical and maximum values are preferred along with the symbols of the parameters being specified and the conditions under which the specification has been made.
2.18 Specify the transient operating conditions of the chip, including all delay times, rise and fall times, hold times, setup times, clock frequencies etc. Include timing diagrams if more clarity is required for each parameter. Include symbols for all parameters being specified and the conditions under which the specification is made.
2.19 Specify AC operating conditions. Specify gains, noise levels, input and output impedances, input and output analog voltage and current levels, frequencies, analog accuracies and tolerances etc. Include symbols for all the parameters being specified and the conditions under which the specification is made.
2.110 In the last section include some typical application circuits and/or applications hints that allow the user/designer to understand the operation of the overall system including the role of external components and any test signals. Also include in this section, the suggested board layout for accurate operation of the device. If possible include a specification of the board material or other substrate being recommended for usage.
2.2 Test Specifications:
2.2.1 Cover page is almost identical to that of the functional specifications with all the nomenclature indicating revisions, dates, initiators, approvals and title.
2.2.2 Provide a block diagram of the test architecture showing all external components and any switching relays, matrices of other auxiliary test structures to be used.
2.2.3 Provide a complete pin I/O description. Note that in many cases the test pin I/O list may be more extensive that the functional pin I/O list since there may be test pins included on the device. The package for test may or may not have the same number of pins. Provide a clear description of the pins and their functions.
2.2.4 Provide a complete list of tests to be carried out. Name each test with an appropriate name and number. Link a test description to each test number.
2.2.5 Provide detailed device specific test procedures for each of the tests specified in 2.2.4 above including the role of external supplies and other signals and expected results and tolerances for the results.
3.0 Challenges in building Specifications
It is one thing to say that specifications should be provided for a design to be done accurately and another to actually do it. This is specially the case if the device is a new device with very little functional or test history behind it.
In most cases no one really knows enough about the device to specify it completely. Typically, information that needs to be input into the specifications is non - existent before the device designed. This is the first hurdle or challenge faced by those who would specify the device.
Therefore it is common practice to have a “ preliminary “ specification which is a specification which has a considerable amount of information but also has a lot of “TBD’s” i.e. “ To be determined “ parameters.
The TBD’s can only be replaced by hard data after the chip has been designed and in some cases after the chip has been fabricated and evaluated.
The test specifications are also in a similar position. Since the operating parameters may be unknown the test specification suffers a similar fate with a TBD’s also.
There is a common practice in test specification development where a number of iterations may be performed on the specification. The first test specification may be “ Comprehensive”. This simply means that there is an overkill of tests included in it. These extra tests provide information for the final test specification after the device is designed and fabricated.
As more and more information becomes available the “ Comprehensive “ specification is trimmed downwards with fewer and fewer tests remaining until a final test specification can be approved.
__________________________________________________________________
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment