Cyclone III stuck at POR?

[Altera_Forum]

Hi, 

 I have problems to get a custom board work, the FPGA seems to be stuck in POR. It's a PCIe card with a EP3C10F256C7N. I attached an excerpt of the schematic to this post.  I have 10 prototype boards, they all show the same problem: nSTATUS is at LOW level and we can't test the boards with JTAG. It's our the second design with a Cyclone III, the first one worked well.  I checked the power supplies, they are well inside the limits. VCCINT is 1.196V, VCCA is 2.497V and VCCIO is 3,282V. I tried to vary VCCA and VCCIO some 0.1V up and down, but without success. VCCIO is sourced directly from the 3.3V of PCIe connector, VCCINT and VCCA are made from this 3.3V with linear regulators. All VCCIO are tied together to the same 3.3V power supply. MSEL[2:0] is set to 010, that should be AS standard POR with 3.3V configuration voltage.  I measured the config and JTAG pins:  nCONFIG: 3.3V nSTATUS: 0V CONF_DONE: 0V nCEO: 0.2V (open?) DCLK: 3.3V nCE: 0.9V (?) nCSO: 3.3V ASDO: 3.3V DATA[0]: 3.3V TDO: 3.3V TDI: 3.3V TMS: 3.3V TCK: 0V  Can nCE or any other config pin hold the device in POR?  The design has migration parts (EP3C5, EP3C16 and EP3C25), therefore I have more VCC and GND pins than required for the EP3C10 connected to the device. I checked all dedicated pins (configuration and power) against a Quartus II 10.1 generated pin list. I compared it with our schematic and with the PCB artwork, but I can't find any mistake. I didn't check all of the I/O connected to the board, but all peripheral devices are powered from 3.3V, so I assume that they're within the I/O limits.  Where is the mistake? What other reason can hold the device in POR?  Regards, Jürgen

[Altera_Forum]

--- Quote Start ---  Here are what I think are the relevant pages from my schematic.  --- Quote End ---   The exposed pad ("pin145") isn't connected in your schematic, I hope you did it otherwise.

[Altera_Forum]

Oh man, if there's a pin 145 exposed pad, then that could be the problem. Thanks for noticing that! 

 I'll work on this and let you know what I find.

[Altera_Forum]

Exposed Pad pin 145? I missed this. I went back and found reference to it in these locations... 

  - AN 466: Cyclone III Design Guidelines, Page 3, note (5)  "The E144 package has an exposed pad at the bottom of the package. This exposed pad is a ground pad that must be connected to the ground plane on your PCB. This exposed pad is used for electrical connectivity and not for thermal purposes."  - Pin Information for the Cyclone III EP3C5 Device, page 7, note 3  "The E144 package has an exposed pad at the bottom of the package. This exposed pad is a ground pad that must be connected to the ground plane on your PCB. This exposed pad is used for electrical connectivity, and not for thermal purposes."  - Altera Cyclone III Handbook, Chapter 1, Page 1-4  "The E144 package has an exposed pad at the bottom of the package. This exposed pad is a ground pad that must be connected to the ground plane on your PCB. This exposed pad is used for electrical connectivity, and not for thermal purposes."  footprint information - http://www.altera.com/devicepackaging/04r00221-02.pdf  I think I can salvage these protoboards with a little bit of solder work since it calls for electrical connectivity and not thermal performance. I'll report back early next week and let you know for sure that this worked for me. I'm sure it will.  Thanks so much for noticing this.

[Altera_Forum]

You stumbled upon one of the popular Cyclone III design faults. There's a good chance to fix it, Altera board users even reported to have connected the exposed pad by drilling a hole from the bottom and soldering a small wire to the pad. 

 P.S.: http://www.alteraforum.com/forum/showthread.php?t=4999 http://www.alteraforum.com/forum/showthread.php?t=4065

[Altera_Forum]

That fixed it! Thanks! 

 Now, I wonder if Jurgen did the same thing.

[Altera_Forum]

--- Quote Start ---  Now, I wonder if Jurgen did the same thing.  --- Quote End ---   Can't be, because he's using a different package.

[Altera_Forum]

Hi, 

 I tried some modifications to my circuit, but it still doesn't work. It's now very close to Figure 9-3 "Single-Device AS Configuration" on page 9-13 of the Cyclone III data book:  nSTATUS is pulled-up to 3.3V with 10k CONF_DONE is pulled-up to 3.3V with 10k nCONFIG is pulled-up to 3.3V with 10k nCE is pulled-down to GND with 10k DATA[0] is connected to the EPCS4 with 22R DCLK, nCSO and ASDO are connected to EPCS4 directly  I attached a scope screenshot. The channels are:  Ch1 (yellow): nSTATUS Ch2 (blue): VCC33 (3.3V) R2: nCONFIG R3: nCE R4: TDOP (the TDI input of the FPGA)  TDI looks somewhat strange, I already tried to cut it from TDOP and pulled it up to 3.3V, but nSTATUS still isn't released. VCC33 (3.3V) rise time is 8ms, I think this is ok, right?  Any ideas what I can try furthermore?  Regards, Jürgen

[Altera_Forum]

Another measurement of the start phase: 

 Ch2 (blue): 3.3V R1 (white): 2.5V  Ch1 (yellow): 1.2V  Any comments?

[Altera_Forum]

Power supply timing looks fine, I can't detect any obvious problem from the shown waveform. The problem is somewhere else.

[Altera_Forum]

Hello FvM, 

 I don't have any other idea what to check. I contacted Altera support, hopefully they can give me a hint.  Thank you for your help, Jürgen

[Altera_Forum]

Should R19 be 10k? And should there be a 10k PU on TMS as well and a 1k PD on TCK. This is going on the CIV GX Starter kit schematic. Please ignore if someone has already brought this up - this chain is getting long.

[Altera_Forum]

I've heard that the TCK signal is sensitive to trace length and noise - can anyone confirm this? I'm told a 1 to 10pF cap to gnd can fix some issues...

[Altera_Forum]

--- Quote Start ---  Should R19 be 10k? And should there be a 10k PU on TMS as well and a 1k PD on TCK.  --- Quote End ---   The Cyclone III handbook recommends 10k pull-ups for both TDI and TDO, but I think it's not very critical. In my circuit I have 1k pull-ups at TDI and TMS and a 1k pull-down at TCK, they're placed on another sheet of the schematic.  Regards, Jürgen

[Altera_Forum]

--- Quote Start ---  The Cyclone III handbook recommends 10k pull-ups for both TDI and TDO, but I think it's not very critical. In my circuit I have 1k pull-ups at TDI and TMS and a 1k pull-down at TCK, they're placed on another sheet of the schematic.  --- Quote End ---    I agree that the pull-up resistor values aren't critical. Using a higher pull-down resistance for TCK has cshown a problem in some cases, where TCK picked up interferent signals, causing random faults in operation.    --- Quote Start ---  I've heard that the TCK signal is sensitive to trace length and noise - can anyone confirm this? I'm told a 1 to 10pF cap to gnd can fix some issues...  --- Quote End ---    I recently reported the case of a Cyclone design, where a capacitor was needed to achieve reliable TCK operation. The FPGA was still recognized by the programmer, but some JTAG action failed, e.g. indirect JTAG programming and SignalTap II operation. If I remember right, some problems with Cyclone III Dev Kits could be also fixed this way. In my understanding, it's a special problem of TCK signal integrity, involving the USB Blaster driver impedance and on-board wiring. I have much more Cyclone I - III designs, where JTAG operations never brought up any issues.

[Altera_Forum]

It looks like we've found the reason for the POR fault, finally. The PCB was manufactured faulty, none of the VCCINT pins were connected to 1.2V. We found this after de-soldering the FPGA from the board. The PCB was supposed to be 100% electrically tested - apparently it was not. 

 Thanks to all your tips and hints!  Regards, Jürgen