cyclone4 JTAG issue

[Altera_Forum]

One of the FPGA's JTAG on our PCB having three cyclone4 FPGA's (EP4CE55F23I7N) is going faulty after some time. 

 I probed and checked the JTAG signal of the FPGA,whose JTAG is going faulty(U2) with the other stable JTAG FPGA's on board(U1,U3) and also with a DIFFERENT DESIGN PCB WHOSE JTAG is STABLE.      I observed no significant difference in the levels and behavior of the signals.     Also, while i was probing theU2 FPGA's JTAG signals, i found that the JTAG first became inconsistent in connecting. I started the JTAG debugger tool and it gave a message that the TDI pin appears to be shorted to ground.After some time the JTAG was completely down and did'nt connect. I measured the TDI pin's resistance wrt ground and found it to be 2 ohm(while in working FPGA it is in kilo ohms).      As this happened during probing, i am suspecting some loading on the JTAG pins of the FPGA going faulty. Then i measured the track lengths of the JTAG signals of this FPGA(TDI,TDO,TMS,TCK) on the PCB and found it to be approx 155 mm each.     Now can this track length create problems with JTAG consistency??   Or there is anything else we should suspect.

[Altera_Forum]

I'd be more concerned about the design's power supplies and general signal integrity. How are the rails for the FPGA(s) being generated? How good are they? Poorly designed power solutions, that present unwanted noise/transitions to the FPGA, can manifest themselves in strange ways. 

 What is different about U2 as compared to the others? Are some of it's I/O pins being subjected to unwanted noise/transients that might be damaging the FPGA? Signals that come from off-board, that are not conditioned locally, can frequently cause issues.  If 155mm was the issue I'd expect you to see JTAG integrity issues straight away and not after a period of time. You also suggest you have another board which works well?  What are you hosting the JTAG chain with - a USB-Blaster, or something else?  JTAG trace lengths can be an issue - the drivers are relatively weak. However, it's unlikely to result in device damage.  Cheers, Alex

[Altera_Forum]

dear alex, 

Is there a specific power up sequence we need to follow for FPGA's?? Presently we are using dual output(3V3 and 1V2)TI-70145 regulator configured to power up VCCINT and then VCCIO of FPGA.(schematic is attached). And 2V5 is powered up from TLV1117 which powers up at start up. Also i need to mention here that similar power supply section has already been used in a single FPGA board and the DESIGN was stable. The only difference in this design is that we are using a common 2V5 regulator for all the VCCA's of three on board FPGA's. And also i am observing that the FPGA going faulty(U2) is located farthest from the 2V5 regulator(though we have put decaps near the FPGA pins).   Also as u pointed out one doubt, the difference between U2 FPGA and other FPGA's on board is that some of it I/O pins are interfaced to a RANDOM LOGIC GENERATOR whose OUTPUT VARIES AT EVERY INSTANT. AND WE HAVE KEPT THOSE PINS UNASSIGNED IN OUR DESIGN SO FAR.  KINDLY CONFIRM THAT WHETHER THIS CAN CREATE SUCH JTAG ISSUES AFTER SOME TIME??

[Altera_Forum]

The "power requirements for cyclone iv devices (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/cyclone-iv/cyiv-51011.pdf)" chapter of the handbook discusses the rail sequencing, amongst other things you need to consider. In short there are no sequence constraints: 

  --- Quote Start ---  You can power up or power down the VCCINT, VCCA, and VCCIO pins in any sequence. The VCCINT, VCCA, and VCCIO must have a monotonic rise to their steady state levels. All VCCA pins must be powered to 2.5V (even when PLLs are not used), and must be powered up and powered down at the same time.  --- Quote End ---    The power supply design may well be proven but the performance of it may well vary from design to design. Different loading and layout will see to that. Nothing you describe is wrong. However, how good are the supplies at the FPGA pins? Have you looked at them with an oscilloscope? What they look like there is what matters. Plenty of local decoupling capacitors can be very important.  I don't think your choice of voltage regulator is appropriate. 250mA for VCCINT for an FPGA that size just doesn't sound like enough to me. Have you planned this with the "powerplay early power estimators (https://www.altera.com/support/support-resources/operation-and-testing/power/pow-powerplay.html)"? What current are you expecting VCCINT to draw? I suspect the planning spreadsheets will estimate it's more than 250mA. Are those regulators getting hot? Is it one of those that's failed (as opposed to the FPGA)?  The 'random logic generator' doesn't concern me. Random transitions are perfectly acceptable providing the signal they are generating conforms to the I/O standard specifications for the FPGA. Any over/under-shoot is what might shorten the life of the device. How that manifests itself might be as simple as the particular I/O pin failing. However, it may well be something else.  You also ask if the USB-Blaster draws current from your board - yes, but not a lot. Refer to the "usb-blaster ii download cable user guide (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/ug/ug_usb_blstr_ii_cable.pdf)". Does it drag your 2.5V rail down when connected/operating? That would be a bad sign.  A single 2.5V linear - like you have - should be enough. Does it get warm? How much current is it delivering? Whether you are simply programming via JTAG or debugging will not significantly affect the current the USB-Blaster is consuming.  I think you need to focus on the regulator for VCCINT. It just doesn't look to be up to the job.  Cheers, Alex

[Altera_Forum]

dear alex, 

We are using sufficient number of decaps close to the FPGA pins and the VCCINT supply is very clean. Now our only concern is the power consumption of VCCINT. We will estimate it with "PowerPlay Early Power Estimators". But i would like to mention that we are using separate dual output(3V3- 500mA and 1V2-250mA) for each EP4CE55F23I7N FPGA. Also we have not used the power estimation tool till now for our power analysis. I would like to mention here that the earlier PCB in which this power section was stable used EP3C16F484I7N FPGA, and there we used somewhat similar FPGA resources.That was why we copied the power section from there in our new design. Now i would like to ask that can this VCCINT failure cause damage to the FPGA's JTAG port?? And also in one of the boards the FPGA's VCCIO and GND pins were found shorted after some time. Kindly suggest. Thanks and regards.

[Altera_Forum]

A EP4CE55 has almost 4 times the resources of a EP3C16, all of which are powered from VCCINT. Whilst you may not be using all of them, and the power consumed by Cyclone IV is (generally) lower that of Cyclone III, the current consumed by your new part is likely to be higher. 

 If the supplies are clean - great. Do they remain clean having left the board powered for a significant amount of time with the FPGAs configured?  As well as filling out the power estimators, remove the output inductors you have on your VCCINT rail and connect up and power your board from a bench supply. That will give you an accurate reading for the current consumed by VCCINT. You will need headroom on this measurement as the bench supply will only give you an average reading. The voltage regulator will be able to supply peak current surges - the FPGA is likely to do this regularly. The decoupling you have looks sufficient. However, if the current is anywhere near the 250mA limit for that channel of the voltage regulator, I'd be concerned.  Could a problem on VCCINT cause JTAG problems? Yes, absolutely. The VCCA rail will only power the JTAG I/O, not any JTAG logic. That is all powered from VCCINT.  Having said all that, if the regulator isn't up to it, the voltage is simply likely to drop causing the FPGA to stop working. It's (perhaps) unlikely to damage the FPGA.  I'm more concerned about the short you have between VCCIO and GND. This almost certainly will be the result of one or more I/O pins being over-stressed, over-driven. Alternatively, but less likely given the power solution you have, the regulator supplying VCCIO for that rail has over-driven the VCCIO pins. Re-check all the signals going into the VCCIO bank that's failed.  Finally, do you have the same fault on multiple boards?  Cheers, Alex