01-17-2019 01:07 PM
We are using Kintex-7 parts in our test equipment products. We have encountered quite a high percentage of failure events with the Kintex-7 part (XC7K70TFBG484-1) where one of the I/O suddenly shows a fixed parasitic resistance to Vcco12 (in the range of 100-200 ohms), or a fixed parasitic resistance to GND (in the range of 50-100 ohms). This parasitic resistance stays fixed even when the device is powered off, indicating that it is a permanent damage. All other I/Os of the device function OK when this happens.
The I/O BUS in which this problem appears is divided across both the HP and HR banks of the Kintex-7 device. The I/O select for the HP bus is SSTL12, and for the HR bus is SSTL135. This "zapping" problem only occurs with the HP banks, never in the HR banks of the Kintex-7 device. In most cases, only one I/O became defective, but in few cases two I/Os were "zapped" by the same event.
Our users connect a target device to be tested (DUT) to the I/O BUS during a 'Standby Mode' whereby the I/O BUS is set as input. The DUT itself has no power connected to it during Standby Mode. We had successfully used the same arrangement for many years, using previous Xilinx devices ( Virtex II Pro, Virtex 4 and Virtex 5) in our earlier generations of our test equipment. The "zapping" problem appears only with the Kintex-7, which has lower inherent protection to ESD than the Virtex 5 (e.g. +/-1000V HBM passing voltage for Kintex-7 compared to the +/-2000V HBM passing voltage for the Virtex 5 and earlier devices).
Assuming that when the user inserts the DUT target devices they cause ESD charges on the I/O lines, we have put low capacitance TVS diodes/ varistors on each and every I/O signal. We are using LXES15AAA1-153 ESD TVS diodes by Murata. The "zapping" problem still unfortunately happens, but at a somewhat reduced frequency. Using standard anti-static precautions (like grounded wrist straps) still does not solve the problem.
I should point out that the "zapping" damage never occurs when inserting DUT devices on the I/O BUS when the Kintex-7 part (and the equipment) is not powered. It occurs only when the equipment is ON and the Kintex device is properly powered on. Similar ESD charges must still be inadvertently applied to the I/O BUS whenever we insert the DUT device. Therefore, I assume that the TVS protection devices we have on each I/O are able to safely dissipate these ESD charges.
1. Since the typical ESD charges by itself apparently do not cause this "zapping" problem when the Kintex-7 is not powered, could it be that the ESD charge just triggers a Latchup situation that causes the damage?
2. Can a controlled reduction of the max current output of the VCCO12 supply for the I/O bus during the Standby Mode (where the ESD event may occur when the DUT is connected to the I/O BUS) mitigate the problem, assuming it is a latchup event?
3. Do we need also reduce the max current output of the VCCAUX during Standby Mode? Both our VCCAUX and VCCO12 power supplies provide very low current during Standby Mode.
4. Since the "zapping" problem occurs only in the HP banks of the Kintex-7 device, can Xilinx provide any hint that will help us solve the problem?
5. If you think that the problem is only the ESD event, not the Latchup, can you advise other TVS diodes than the LXES15AAA1-153 that we should use on the I/Os?
David Y. Feinstein, Phd.
02-07-2019 09:48 AM
This is a rather complicated and large issue to discuss on the forums. It may be on route to a lengthy and messy road which may not necessarily lead to a solution. So on an alternate direction I recommend trying to get a Xilinx Service Request going either by your self or through your FAE. You can always contact Xilinx sales offices or the Xilinx authorized distributor the parts were purchased from. Good luck!
02-07-2019 01:01 PM
Thank you for your suggestion.
Can you assist me to open a webcase so that we get the Service Request number? We are buying the Xilinx parts in quantity via Avnet for the past 16 years but now they no longer have their own FAE.
We tried to use your web site to open a Service Request but it keep sending us in circles (as discussed elsewhere in your forums) without having been able to open the webcase...