Multirate processing, sampling rate conversion, or interpolation and decimation as it is known, is a clever technique in DSP. As analog and mixed signal design engineers we have learned to use this technique in various product designs for our customers. It offers an added degree of freedom in the design of mixed signal integrated circuits that may be of help to other professionals such as us.
Multirate processing finds use in signal processing systems where various sub-systems with differing sample or clock rates need to be interfaced together. At other times multirate processing is used to reduce computational overhead of a system. For example, an algorithm requires k operations to be completed per cycle. By reducing the sample rate of a signal or system by a factor of M, the arithmetic bandwidth requirements are reduced from kfs operations to kfs/M operations per second. fs is the sampling rate. M is the decimation factor.
In other applications, resampling a signal at a lower rate will allow it to pass through a channel of limited bandwidth. In another application a high accuracy delta-sigma A/D converter can be made with very high modulation rate at the front end followed by a decimator ( down converter) to reduce the sampling rate and provide converted samples at or near the Nyquist rate.
Applications for this technique abound, if understood by the practitioner. The challenge is that it is not easy to pick up a book or a paper on DSP and understand Decimation and Interpolation to an intuitive extent. This causes hesitation in usage.
A tutorial paper has been written to aid in further understanding of this fascinating topic. Read it at http://www.signalpro.biz/sampling_rate_conv.pdf.
Friday, February 20, 2009
Tuesday, February 17, 2009
Developing Specifications for an analog/RF/MMIC ASIC
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.
__________________________________________________________________
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.
__________________________________________________________________
Wednesday, February 4, 2009
ASIC success factors based on customer - vendor relationships
ASIC success is something that all customers and ASIC vendors pray for. For the customer the issue is one of his/her credibility and recognition within his/her own organization and potential gain/loss of funding. The issue for ASIC vendor is his/her reputation, revenue and long term prosperity. Whichever side one is on, any information on succeeding with an ASIC product can only come in handy.
Over the past 35 years, my involvement with ASICs, first as an employee of large systems companies and then latterly ( 21 years) in a smaller "ASIC - centric" company I have learnt some lessons which I thought might be useful for others. Therefore this post.
The following success factors are in no particular order. Yet all are equally important. If the interested person makes use of these ideas then his/her success with ASICs will be greatly enhanced. That is my earnest hope.
1.0 Underestimation of time and money: The success or failure of an ASIC actually starts right at the beginning, when the vendor is asked for a quotation. Many times the vendor thinks that by underbidding the project he may improve his chances of getting the business. As a matter of fact, this is true in many cases. A low bidder wins. However, the customer may not realize that two things are about to happen:
(A). The vendor cannot possibly complete the project in the time and money originally quoted so he asks for more time or money or both, in many ingenious ways.
(B) The vendor fails to do a complete job on the ASIC and releases the ASIC to fabrication anyway. Of course the probability of failure is very high, since due diligence may not have been done.
Both of these options lead to negative consequences. One of the most serious being loss of trust by the customer, and the death of a close friendly relationship between the two. It is very hard to salvage the project after this has happened.
Therefore for ASIC success, an accurate estimation of time and money is critical. If the vendor estimates a higher amount, he still has to live by it and quote it. In spite of this the wise customer will add at least 20% 0r more to both these quantities as contingency planning.
2.0 Schedule: This is a corollary to the first factor. Establishment of a reasonable workable schedule is one of the most important success factors for ASICs. Similar comments hold as above. When schedules become too tight or unworkable the project can continue for a while in cloud cuckoo land but the cuckoos will ultimately come home to roost as the time runs out. The result may be (i) ASIC not complete (ii) ASIC done badly to satisfy customer push to meet an unworkable schedule leading to failure of the ASIC at probe or bench test. After this it is very difficult to continue with the project because it may take a very long time to debug and fix the ASIC. Again a contingency plan should add more time to take into account any unknown factors from completely wrecking the schedule and hence the ASIC.
3.0 ASIC development agreements: A carefully thought out and written ASIC development and supply agreement is an absolute must for success. Agreements should contain, at a minimum, a clear and detailed SOW for each phase of the project, review process, Engineering Change Order( ECO) procedures, a program plan as accurate as can be at this initial stage, payment schedule and terms, communication procedures between the vendor and customer and any other legalities ( boiler plate). Functional and test specifications may or may not be included. If a separate conceptual/feasibility study was done before the actual ASIC project was started ( highly recommended) then both specifications should be part of the agreement.
4.0 Customer expectations: Customer expectations are a very important success factor for an ASIC project. Customer expectations are really set by his/her view of the vendor and the information that vendor supplies. It is imperative that a set of realistic ( or slightly pessimistic, [I daresay], expectations) be the rule. I know that if the expectations are very pessimistic then the customer will decide not to do the project. Conversely, if the customer expectations are too high then when reality sets in, the negative feelings may cause untold misery to both parties. I believe that one of the critical jobs that a vendor must do is to manage customer expectations in an effective and positive manner.
5.0 Design tools: Lets make sure that the appropriate design tools are available both to the vendor and customer. At a minimum, a reasonable system simulator, a circuit simulator, a layout tool, a debug tool and a documentaion tool is essential. Today this is not a problem, since CAD tools are freely available under a variety of license options. A corollary to this, is that the vendor must know how to make effective use of the tool. Currently CAD tools have become so complicated and massive that sometimes this very fact causes problems. I think that the rule should be, to use the simplest and most user friendly tool appropriate to the job. The customer needs to have some way to review the work being done and to help if any issues arise. Therefore the customer should also have access to some tools which allow him/her to do his bit.
6.0 Fabrication models and design rules: This is very important and has major ramifications. As shown in an earlier post, one of the ways to realise a successful ASIC to through extensive simulation, clean layout and verification of the layout before submission to a fabrication facility. Accurate device models and design rules must be supplied by the fabricator and packaging houses. Any inaccuracies in this data will cause untold problems, during and after the fabrication of the ASIC and may render a ASIC completely useless. So lets make sure we pick a good fabricator and packaging house who can supply accurate models.
7.0 Design expertise: The vendor should make sure that the design expertise exists in the company for a particular type of ASIC. Competence is what is required. The augmentation of expertise with CAD tools is great and perhaps competence with the CAD tools is part of the expected competence. If the appropriate design expertise for a certain part of the ASIC does not exist within the company, then ask for help within the larger ASIC vendor or consultant community to fill the gap.
8.0 Full disclosure to the customer: It is essential that the vendor and customer disclose any issues that may be troubling or which may impact the success of the ASIC. Colloquialy, "lets be up front" with each other to get the maximum benefit from each others expertise. Anything that is hidden will eventually be found out and usually at the worst possible time.
9.0 Customer - vendor relationship: This is one of the most important success factors for ASIC success. A close, cordial, mutually respectful and friendly relationship between the customer and vendor, in my opinion, is a very important success factor. Even in times of stress ( for whatever reason) a close relationship will help to get over any issues being generated by the project. A close friendly relationship is so important that I rate it as the number one success factor for ASIC success.
10.0 Communications between the customer and the vendor: Another important success factor is the level of communications between the customer and vendor. Regular reviews, informal or formal conversations between the appropriate members of the customer/vendor team make all the difference in the world. Specially to catch any problems in their infancy, before they become big problems. E-mail, video teleconferencing, telephone, etc. whatever means are most effective should be used often and regularly to achieve a close communication link.
11.0 Use of ECOs ( Engineering change orders): In some cases, even though due diligence was done, a change may be required by the customer after the project starts. I strongly recommend the use of ECOs to prevent problems due to "MISSION CREEP", the biggest problem in some major projects. Obviously it is not easy to eliminate this, but the ECO allows both parties to do the needful in a friendly and professional manner. The change to be done is discussed, a new quote for time and money is generated and the program plan is amended in such a manner that both customer and vendor are satisfied.
12.0 Multiple iterations for large ASICs: The rate at which there are first pass successes for ASICs has risen steadily. However, when the ASIC is complex for any reason ( Large analog and digital content, different types of simulation conditions, unknown design parameters etc), multiple iterations should be factored in right at the beginning and customer and vendor should clearly understand that this is the case. The number of iterations required varies from project to project. Sometimes the vendor may fail to inform the customer of this fact and thereby fail to manage customer expectations as mentioned above leading to a failure of the project.
13.0 Post fabrication analysis tools: If the ASIC is small and uncomplicated, then the probability is, that it will be a first pass success and no other work will be needed post fabrication. However, when the ASIC is complex ( as described above), it is very probable that multiple iterations will be required to get it to production status. In order to effectively analyze performance problems or debug the ASIC some analysis tools and equipment is neccessary.
An analytical prober with a low capacitance, high impedance probe capable of probing down to
1 micron is neccessary. Access to a Focused Ion Beam ( FIB) resource is becoming more and more popular. Appropriate laboratory test equipment is neccessary. A PCB design, layout and fabrication resource is required. This is of course not a comprehensive list. Some of this equipment and tools may be acquired internally. However some expensive items like the FIB tool may be rented as needed.
14.0 Conclusions: The above musings are a result of my experience. The success factors listed above are by no means exhaustive. I would welcome comments from peers on their experiences and permission to add their recommendations to this list. Finally I sincerely hope that this post is useful and leads to better ASICs and great ROI for our customers.
Over the past 35 years, my involvement with ASICs, first as an employee of large systems companies and then latterly ( 21 years) in a smaller "ASIC - centric" company I have learnt some lessons which I thought might be useful for others. Therefore this post.
The following success factors are in no particular order. Yet all are equally important. If the interested person makes use of these ideas then his/her success with ASICs will be greatly enhanced. That is my earnest hope.
1.0 Underestimation of time and money: The success or failure of an ASIC actually starts right at the beginning, when the vendor is asked for a quotation. Many times the vendor thinks that by underbidding the project he may improve his chances of getting the business. As a matter of fact, this is true in many cases. A low bidder wins. However, the customer may not realize that two things are about to happen:
(A). The vendor cannot possibly complete the project in the time and money originally quoted so he asks for more time or money or both, in many ingenious ways.
(B) The vendor fails to do a complete job on the ASIC and releases the ASIC to fabrication anyway. Of course the probability of failure is very high, since due diligence may not have been done.
Both of these options lead to negative consequences. One of the most serious being loss of trust by the customer, and the death of a close friendly relationship between the two. It is very hard to salvage the project after this has happened.
Therefore for ASIC success, an accurate estimation of time and money is critical. If the vendor estimates a higher amount, he still has to live by it and quote it. In spite of this the wise customer will add at least 20% 0r more to both these quantities as contingency planning.
2.0 Schedule: This is a corollary to the first factor. Establishment of a reasonable workable schedule is one of the most important success factors for ASICs. Similar comments hold as above. When schedules become too tight or unworkable the project can continue for a while in cloud cuckoo land but the cuckoos will ultimately come home to roost as the time runs out. The result may be (i) ASIC not complete (ii) ASIC done badly to satisfy customer push to meet an unworkable schedule leading to failure of the ASIC at probe or bench test. After this it is very difficult to continue with the project because it may take a very long time to debug and fix the ASIC. Again a contingency plan should add more time to take into account any unknown factors from completely wrecking the schedule and hence the ASIC.
3.0 ASIC development agreements: A carefully thought out and written ASIC development and supply agreement is an absolute must for success. Agreements should contain, at a minimum, a clear and detailed SOW for each phase of the project, review process, Engineering Change Order( ECO) procedures, a program plan as accurate as can be at this initial stage, payment schedule and terms, communication procedures between the vendor and customer and any other legalities ( boiler plate). Functional and test specifications may or may not be included. If a separate conceptual/feasibility study was done before the actual ASIC project was started ( highly recommended) then both specifications should be part of the agreement.
4.0 Customer expectations: Customer expectations are a very important success factor for an ASIC project. Customer expectations are really set by his/her view of the vendor and the information that vendor supplies. It is imperative that a set of realistic ( or slightly pessimistic, [I daresay], expectations) be the rule. I know that if the expectations are very pessimistic then the customer will decide not to do the project. Conversely, if the customer expectations are too high then when reality sets in, the negative feelings may cause untold misery to both parties. I believe that one of the critical jobs that a vendor must do is to manage customer expectations in an effective and positive manner.
5.0 Design tools: Lets make sure that the appropriate design tools are available both to the vendor and customer. At a minimum, a reasonable system simulator, a circuit simulator, a layout tool, a debug tool and a documentaion tool is essential. Today this is not a problem, since CAD tools are freely available under a variety of license options. A corollary to this, is that the vendor must know how to make effective use of the tool. Currently CAD tools have become so complicated and massive that sometimes this very fact causes problems. I think that the rule should be, to use the simplest and most user friendly tool appropriate to the job. The customer needs to have some way to review the work being done and to help if any issues arise. Therefore the customer should also have access to some tools which allow him/her to do his bit.
6.0 Fabrication models and design rules: This is very important and has major ramifications. As shown in an earlier post, one of the ways to realise a successful ASIC to through extensive simulation, clean layout and verification of the layout before submission to a fabrication facility. Accurate device models and design rules must be supplied by the fabricator and packaging houses. Any inaccuracies in this data will cause untold problems, during and after the fabrication of the ASIC and may render a ASIC completely useless. So lets make sure we pick a good fabricator and packaging house who can supply accurate models.
7.0 Design expertise: The vendor should make sure that the design expertise exists in the company for a particular type of ASIC. Competence is what is required. The augmentation of expertise with CAD tools is great and perhaps competence with the CAD tools is part of the expected competence. If the appropriate design expertise for a certain part of the ASIC does not exist within the company, then ask for help within the larger ASIC vendor or consultant community to fill the gap.
8.0 Full disclosure to the customer: It is essential that the vendor and customer disclose any issues that may be troubling or which may impact the success of the ASIC. Colloquialy, "lets be up front" with each other to get the maximum benefit from each others expertise. Anything that is hidden will eventually be found out and usually at the worst possible time.
9.0 Customer - vendor relationship: This is one of the most important success factors for ASIC success. A close, cordial, mutually respectful and friendly relationship between the customer and vendor, in my opinion, is a very important success factor. Even in times of stress ( for whatever reason) a close relationship will help to get over any issues being generated by the project. A close friendly relationship is so important that I rate it as the number one success factor for ASIC success.
10.0 Communications between the customer and the vendor: Another important success factor is the level of communications between the customer and vendor. Regular reviews, informal or formal conversations between the appropriate members of the customer/vendor team make all the difference in the world. Specially to catch any problems in their infancy, before they become big problems. E-mail, video teleconferencing, telephone, etc. whatever means are most effective should be used often and regularly to achieve a close communication link.
11.0 Use of ECOs ( Engineering change orders): In some cases, even though due diligence was done, a change may be required by the customer after the project starts. I strongly recommend the use of ECOs to prevent problems due to "MISSION CREEP", the biggest problem in some major projects. Obviously it is not easy to eliminate this, but the ECO allows both parties to do the needful in a friendly and professional manner. The change to be done is discussed, a new quote for time and money is generated and the program plan is amended in such a manner that both customer and vendor are satisfied.
12.0 Multiple iterations for large ASICs: The rate at which there are first pass successes for ASICs has risen steadily. However, when the ASIC is complex for any reason ( Large analog and digital content, different types of simulation conditions, unknown design parameters etc), multiple iterations should be factored in right at the beginning and customer and vendor should clearly understand that this is the case. The number of iterations required varies from project to project. Sometimes the vendor may fail to inform the customer of this fact and thereby fail to manage customer expectations as mentioned above leading to a failure of the project.
13.0 Post fabrication analysis tools: If the ASIC is small and uncomplicated, then the probability is, that it will be a first pass success and no other work will be needed post fabrication. However, when the ASIC is complex ( as described above), it is very probable that multiple iterations will be required to get it to production status. In order to effectively analyze performance problems or debug the ASIC some analysis tools and equipment is neccessary.
An analytical prober with a low capacitance, high impedance probe capable of probing down to
1 micron is neccessary. Access to a Focused Ion Beam ( FIB) resource is becoming more and more popular. Appropriate laboratory test equipment is neccessary. A PCB design, layout and fabrication resource is required. This is of course not a comprehensive list. Some of this equipment and tools may be acquired internally. However some expensive items like the FIB tool may be rented as needed.
14.0 Conclusions: The above musings are a result of my experience. The success factors listed above are by no means exhaustive. I would welcome comments from peers on their experiences and permission to add their recommendations to this list. Finally I sincerely hope that this post is useful and leads to better ASICs and great ROI for our customers.
Subscribe to:
Posts (Atom)
